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@ Method and apparatus for validating travelling object-oriented programs with digital signatures. 



(57) A method of operating computers in accord- 
ance with an enhanced object-oriented prog- 
ramming methodology creates a framework for 
efficientiy perfbnnlng automated business 
transactions. The object-oriented programming 
methodology is used in conjunction with a 
travelling program, i.e., a digital data structure 
which includes a sequence of instructions and 
associated data which has the capabOity of 
detennining at least one next destination or 
recipient for receiving the travelling program 
and for transmitting itself, together witii all 
relevant data detemnined by the program to the 
next recipient or destinatbn Using the methods 
described herein, the data is more closely 
bound to the program in such a way tiiat objects 
may be most efficientiy transferred from one 
computer user to another without the objects 
being previously known to the recipient com- 
puter user. The present invention utilizes object 
"cells" which are data structures stored, for 
example, on a disk that reflects a collection of 
(related) object instances whose execution has 
been suspended, and which can be resumed 
later on the same or a different platform. The 
collection of object instances can be gathered 
together into cells (or "electronic fomfis") suit- 
able for storage or transmission to anotiier 
computer user in such a way that instances are 
unambiguously bound to their respective dass 
definition. The present invention also creates 
improved tools for creating and using cells so 
tiiat electronic fbnrrs can be defined using 
object-oriented techniques while blowing such 
fomns to be e^Qy transferred anusng a diverse 
populatbn of computer users without den^nd- 
ing that all users nraintain compatible libraries 
of all object-class definition programs and witti- 
out demanding that all users maintain identical 



synchronized versions of that dass. The inven- 
tion provides a digital signature methodology to 
insure security and integrity, so that electronic 
fbnms (i.e., cells) composed of a collection of 
objects can be received and executed by a user 
wiUiout putting the user at risk that some of tiie 
object dasses embedded in the cell might be 
subversive "trojan horse" programs that might 
steal, destroy or otiierwise compromise the 
security or integrity of tiie user's system or data. 
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SPECIFICATION 

Field of the Invention 

The invention generally relates to apparatus and 5 
a nr^ethod for operating digital computers under the 
control of object-oriented programs. More particular- 
ly, the invention relates to a method and apparatus for 
validating unique travelling object-oriented programs 
using digital signature methoddogy. io 

Related Applications 

This application is related to allowed application 
Serial Number 07/863,552 filed on April 6, 1992, en- is 
titled, "Method and Apparatus for Creating, Process- 
ing and Using Travelling Programs" (hereinafter 
'Travelling Program Application") and to application 
Serial Number 07/883,868, entitled "Computer Sys- 
tem Method and Apparatus Using Program Authoriza- 20 
tion Information (hereinafter "Program Authorization 
Information Application"). 

BACKGROUND AND SUMMARY OF THE 

INVENTION 25 

The present invention is directed to apparatus 
and method for operating a digital computer in accor- 
dance with a powerfully enhanced object-oriented 
programming methodology. 30 

In object-oriented programming using existing 
object-oriented languages, such as, "C," and "Small 
Talk," programmers are able to define object "data 
types' (or "classes") which are data structures each 
associated with a program that knows how to process 35 
that data type. Object-oriented programming pemriits 
existing programs to be reused and extended without 
having to modify the program. This feature of object 
oriented programming known as the "inheritance 
feature" and Is the ability to define new data type 40 
classes derived as "extensions" of other (more funda- 
mental) data classes. 

The extension dass only needs to define those 
functions (known as the objecfs "methods") for the 
new data type which differ from the existing ("base") 45 
class. Such methods may be entirely new or may su- 
persede (by replacing or augmenting) methods de- 
fined for the base dass. This simplifies the creation 
of novel variations of existing data classes, either by 
adding new functions or by superseding (modifying) 50 
existing functions. 

Some object-oriented methodologies allow "mul- 
tiple inheritance" whereby there can be more than one 
"base" dass from which a given dass inherits char- 
acteristics. The present invention contemplates the 55 
possible use of multiple inheritance. The lineage of a 
given dass is the aggregate set of its base dass(es) 
together with the base class' lineage. 



Using more conventtonal "procedural" progranv 
ming methodologies, different data types are proc- 
essed in different manners based upon processing 
rule defined for the data type. Object-oriented pro- 
gramming provides a different processing methodol- 
ogy. Each individual occurrence of a programmer-de- 
fined object data type or dass is known as an "in- 
stance" of that dass. Once a dass is defined, then its 
data type can be used over and over again in different 
programs with no extra programming efforL 

The dass program definition for each data type 
defines the fundions that can be applied to instances 
of that data type. Programs use objects by invoking 
one of the objects methods (i.e., the functions that 
can be applied to instances of that data type) in con- 
jundion with a particular instance of that object The 
method then processes that particular instance of 
data. 

Thus, one of the strengths of object-oriented pro- 
gramming methodology is that the same method 
name can be implemented differently in different 
data type classes. An application program can per- 
fonri a "generic" operation on data without having to 
be concerned about exadly how it is implemented. 
This facilitates the addition of new varieties (classes) 
of data types with minimal changes, if any, to appli- 
cation programs using these types. 

The logic to perform these "methods" is built into 
each data dass once. In this fashion, the way in which 
programs use such data types is simplified by allow- 
ing different data types to each implement a particu- 
lar fundion in a way appropriate to that data type. 

Objed-oriented programming thus provides a 
different methodology for companmentalizing pro- 
grams which is highly useful in many different com- 
plex application areas. In objed-oriented program- 
ming, data is not typically treated as an isolated bit- 
stream, but rather, it is bound to a program which 
manages the data. 

This feature of objed-oriented methodologies- 
the ability to have a particular fundion operate differ- 
ently on a variety of data types- is known as "poly- 
morphism." 

Polymorphism permits a program to operate on 
data without being concerned with what that data rep- 
resents. The polymorphic feature of object-oriented 
methodology permits a particular operation to be inv 
plemented in different ways depending upon the data 
type so that the function will be performed appropri- 
ate to that data type. An example of polymorphism 
may, for example, involve a "multiply" operation. For 
real scalar data types, two scalers are arithmetically 
multiplied together. But for matrix data types, the 
"multiply" method could be implemented to yield the 
more involved "matrix" multiplication. By treating 
these as objects, program designera can use multipli- 
cation without worrying about whether the particular 
operands were real numbers or matrices. Then, at 
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some future time, for example, a new "complex" num- 
ber data type with yet a different multiply mechanism 
could be introduced into existing programs with no 
further programming effort 

Another example of object-oriented methodology 
may involve objects associated with a graphical dis- 
play. Most of such objects would have a "quick" dick 
method that would be invoked whenever the mouse 
pointer lies atop the objecf s associated graphical inrv 
age and the user clicks the nfK)use switch. 

Consider graphical display of a group of buttons. 
Each "button" graphic may be represented and con- 
trolled by a separate instance of the "button" class. 
Other types of graphical items, such as data fields, 
will be controlled with instances of their own respec- 
tive classes. It would be possible to treat an "icon" as 
a special class of "button" but one which has addition- 
al or nrK)dif ied characteristics. 

In developing the "icon" dass as an extension of 
"button," all of the method routines for "button" would 
be effective for the "icon" dass, except those which 
are specifically supplied for the distinct "Icon" dass 
definition. Whenever the user clicks the mouse 
switch, the system determines the items over which 
the mouse appears to be positioned and invokes the 
"dick" method for the object instance associated with 
that graphical item. 

Different functions such as "scroll contents up," 
"delete this object," "print contents," or "handle 
mouse- button-click request" may be interpreted dif- 
ferently depending upon the particular graphical ob- 
ject involved. Allowable functions are defined when 
the data is defined, not each time the data is used. 

The present invention is directed to significantly 
enhanced object-oriented programming methodolo- 
gies which create a framework for efficiently perform- 
ing automated business transactions. The object-ori- 
ented programming methodology of the present in- 
vention is particularly useful in the context of the ap- 
plicant's "travelling program methodology" described 
in the above-Identified Travelling Program patent ap- 
plication, which has been expressly incorporated in 
its entirety by reference herein. 

A travelling program is a digital data structure 
which includes a sequence of instructions and asso- 
ciated data which has the capability of determining at 
least one next destination or recipient for receiving 
the travelling program and for transmitting itself, to- 
gether with all relevant data determined by the pro- 
gram to the next recipient or destination. Using the 
methods described herein, the data is more dosely 
bound to the program in such a way that objects may 
be most efficiently transferred from one computer 
user to another without the objects being previously 
known to the recipient computer user. 

The present invention permits data to be struc- 
tured and maintained as an object with the highest de- 
gree of security and stored and sent around from one 



computer user to another. 

The present Invention also permits application 
programs to be developed more efficiently than here- 
tofore possible through the efficient creatron of reus- 
5 able programming pools. Using the present invention, 
individual objects may be transferred to other user 
destinations as desired. 

The present Invention utilizes objed "cells." Acell 
is a data structure stored, for example, on a disk that 
10 reflects a collection of (related) objects instances 
whose execution has been suspended, and which 
can be resumed later on the same or a different plat- 
form. The collection of object instances can be gath- 
ered together into cells (or "electronic forms") suitable 
15 for storage or transmission to another computer user 
in such a way that Instances are unambiguously 
bound to their respective class definition. 

The present invention provides the useful capa- 
bility of permitting an electronic form to be built up 
20 from arbitrary object-oriented data dass components 
with the data dass definition programs being trans- 
mitted as part of the electronic form together with the 
underlying object instances values. 

The present invention also creates improved 
25 tools for creating and using cells (electronic forms) so 
that electronic forms can be defined using object-ori- 
ented techniques while allowing such forms to be 
easily transferred among a diverse population of 
computer users-without demanding that all users 
30 maintain compatible libraries of all object-class defi- 
nition programs and without demanding that all users 
maintain identical synchronized versbns of that 
class. 

Thus, the present invention facilitates the trans- 

35 fer of such a cell via electronic mail to another user 
without concern as to whether the recipient has all the 
necessary object classes, or whether such classes 
reflect the version properly corresponding to the par- 
ticular data transfer. The cells may be Invoked as ob- 

40 jects by other cells. 

The invention provides a digital signature meth- 
odology to insure security and integrity, so that elec- 
tronic forms (i.e., cells) composed of a collection of 
objects can be received and executed by a user with- 

45 out putting the user at risk that some of the object 
classes embedded in the cell might be subversive 
"trojan horse" prc^rams that might steal, destroy or 
otherwise compromise the security or integrity of the 
user's system or data. 

50 Indicia stored in the object instances them- 

selves to locate the associated dass definition pro- 
gram. This indudes, for example, the name of the ob- 
ject dass instance. 

Unique ways are described herein of binding data 

55 Instances stored in a cell to their respective object 
class programs such that the correct, compatible, 
class definition program is assured of operating on 
the existing instance data when the cell is reloaded 
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from storage when commencing subsequent execu- 
tion. 

This provides integrity by insuring that changed 
"library" or template versions of a class program can- 
not inadvertently operate on older instance data; or 
that other incorrect versions of a dass program can- 
not be inadvertently used (and cause confusion or 
damage) when a celt is activated at different times by 
a variety of users (recipients) [even if one of the users 
may have a class program with a matching name]. 
The unambiguous binding between instance and 
class may be provided in a variety of ways including: 

• by binding an object instance in a cell to its 
dass by including the class definition-i.e., the 
class program logic itself, whether it be in 
source, p-code or machine code-as part of the 
cell data structure. 

• By binding an object instance in a cell to its 
dass by including in the cell a [cryptographic] 
HASH of at least one of: the SOURCE instruc- 
tions (or normalized version thereof); the pseu- 
do-code (p-code) instructions resulting from 
compilation; or the nrtachine language code re- 
sulting from compilation-for the class program 
definition. 

This binding correlates to each instance with pre- 
cisely the correct corresponding class progranrvso 
that another dass with the same name, or an anach- 
rontetic version (too old or too new) of the dass- 
cannot be inadvertently selected to operate on the ex- 
isting version of instance data, when the cell is reload- 
ed. This is especially useful for class programs that 
perform aitical or sensitive functions. In this fashion, 
"master" dass definitions may be changed without 
impairing or confusing existing instances that depend 
on the spedf ication of the dass definition at the time 
the instance was created. 

In accordance with the present invention, critical 
portions of the cell may be digitally signed so that they 
cannot be acddentally or mischievously altered be- 
tween the time the cell is stored and it \s reused (pos- 
sibly by another user). However, non-critical portions 
of the cell are not digitally signed so that they can be 
adjusted to accomnrtodate the optional inclusion or ex- 
clusion of non-critical information, or information 
which can be validated in other ways. Thus, object 
program CLASS definitions can be stored in a digitally 
signed format so they cannot be corrupted. In some 
environments, not all object dass definition programs 
need to be digitally signed-only the ones which per- 
form critical operations. (Such as accessing files; or 
invoking external programs written in assembler lan- 
guage, C language, or other modules which execute 
outside of direct interpreter control). 

Such critical portions typically indude: the struc- 
ture and values of the data and objects, coupled with 
at least an unambiguous binding to at least one cono- 
patible version of each critical object dass program 



definitiorhusually induding the hash value of a ver- 
sion of the program. 

The present invention contemplates that each 
class can be further digitally signed in conjunction 

5 with the authorization defining the operations or func- 
tions which that dass is permitted to perform. This 
authorization is defined by a program authorization 
information data structure as described in above- 
identified copending application U.S.S.N. 

10 07/883,868 entitled "Computer System Method and 
Apparatus Using Program Authorization Informa- 
tion." This application has been expressly Incorporat- 
ed herein by reference. 

This allows automatic detection of corrupted or 

15 malidous cells. It also provides the safety feature to 
insure that untrusted classes (instances) do not have 
the capability (either through program faults, ordelitv 
erate mischief) to cause damage. This allows means 
to MIX TRUSTED and UNTRUSTED dasses-provid- 

20 ing the ability to use casual instances (and classes) 
to supply innocuous or do limited function in conjunc- 
tion with more powerful dasses-assuring that the un- 
trusted dasses can do nothing surreptitiously. This 
also provides the capability to guard against object- 

25 oriented analogies to the Morris Internet virus/worm 
which was able to cause untrusted code to operate in 
a trusted state. 

Using this methodology, the image of the dass 
(either source, p-code, or otherwise) can be inserted 

30 or removed from the cell after it is digitally signed, 
without impairing the integrity of the cell. 

The present invention also provides methodology 
so that versions of a dass program are able to proc- 
ess instances which were created by different ver- 

35 sions of the dass program. This is done by associat- 
ing with the data instance the version of the class pro- 
gram that created it (or last n^nipulated it), and by al- 
lowing each version of the dass program to specify 
the set of data versions which it supports. 

40 The present invention provides a methodology 
for repair or upgrade of an existing celt, whereby the 
class definition stored or referenced by the existing 
cell can be extracted and replaced with a revised (or 
corrected) definition-yet without sacrificing integrity 

45 even if the cell has been digitally signed. 

It provides a methodology whereby one cell (elec- 
tronic form), composed of a variety of objeds, can be 
stored and restored to execution on the same or other 
computers. 

50 It permits entire cells themselves to be invoked 
and processed as objects by other cells. This allows 
the cross-merging of data and processing from cell to 
cell; and the means for handling complex systems of 
cells in which the cell then^elves interact It permits 

55 cells to cause their own transnrtission from user to 
user through the use of electronic mail or other ser- 
vices. It allows the indusion of cells within other cells, 
as well as the ability of a cell to later re-separate in- 
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tenor cells. The invention also allows an isolated por- 
tion of its interior objects to be isolated and used to 
create a subcelL 

The invention teaches how various classes to be 
written in different languages (such as *'6ASIC" and 
"REXX," for example) yet be combined into a conrtmon 
object cell. The invention teaches how disparate lan- 
guages, such as REXX and BASIC can be combined 
so that a dass defined using one progrannming lan- 
guage can be extended from a class written in an- 
other language. 

In another aspect of the invention, programs can 
create, process and manipulate objects for which 
either the class, the methods, or both, are dynamical- 
ly determined independently (and after) either the 
specification or compilation of the program. This is 
possible because both the dass and method names 
are controlled by string values, which permits them to 
be dynamically determined based on any inputs, de- 
cision and string manipulations. 

Therefore, objects may be created based strictly 
on names-which may be entered as data by a user, 
computed dynamically based on run time values, or 
read from a file. Another aspect of the invention is that 
class binding is performed at execution time as they 
are used-so that no special "linkage editing" step Is 
required to bind various dasses into an "executable" 
module. 

The present invention advantageously permits 
object oriented programs to be combined with travel- 
ling programs to allow travelling programs to be con- 
structed using object oriented techniques. It pemnits 
travelling programs to be processed as objects them- 
selves [by other travelling programs]. 

The present invention penmits digital signatures 
can be used with travelling objects so that associated 
class [program] definitions cannot be corrupted, ma- 
nipulated, or altered in definition. It permits digital sig- 
nature technology to be used for security and integrity 
purposes to limit the computer and data resources 
that can be processed by instances of particular ob- 
ject dasses. and the type of processing that can be 
done. 

It permits a network of computer users to ex- 
change data containing a plurality of object instances 
such that: 

the redpient can safely perform at least one of 
the methods In the transmitted object instances, with- 
out danger of malidous damage or compromise of the 
recipienfs data. 

One of the features of this invention is the ability 
to develop programs In which data variables are not 
inherently bound to a particular object dass. The 
present invention allows a programmer to develop 
programs in which the class of variables can be freely 
changed during the execution of the program to re- 
flect any object d ass-even those which were not con- 
templated at the time the program was written. 



Another feature of this programming invention is 
the ability for different instances of the same object 
to possess substantially different sets of assodated 
data fields. 

5 Another feature of thte Invention is the ability 

whereby a collection of mutually associated instanc- 
es, typically associated with several dasses, can be 
written from their execution state into a saved data 
file; this is done in such a way that the programs 

10 which define the instances' dasses are themselves 
unambiguously bound into the saved data file. In this 
invention, such a saved data file shall be called a 
"(^11." 

This invention allows the proper reloading of a 

15 c^l so that ail instances, data associated with the in- 
stances, and the programs assodated with the in- 
stances are recovered with full fidelity so that execu- 
tion processing of the overall cell can commence at 
some future time. 

20 A feature of this invention is that the cell can be 
treated as an object itself, so that the execution state 
associated with the cell at the time of its saving can 
be Invoked at some later time. 

In the present embodiment of the invention, in 

25 each cell there is one particular object instance which 
is considered the 'Yace" of the cell. Whenever a re- 
quest is made to a cell to perform a method, it is the 
method of the face instance which is activated. 
Hence, whereas a cell may contain many constituent 

30 instances, it is the face instance which is responsible 
for handling requests for overall cell activity. 

It is a feature of this invention that the language 
in which the dasses are defined is not spedf ic to one 
computer type, and that it may t>e processed or inter- 

35 preted across a broad range of different computer ar- 
chitectures and operating systems. 

It is a feature of the invention that the actual logic 
defining the object dasses may be stored in and car- 
ried as part of a stored cell. This serves at least two 

40 benefits: 

the cell retains integrity even if the assodated 
class-defining program is changed. In other art, 
where the dass-deflnition is only loosely coupled to 
its instances, it is dangerous to ever change (or "inv 

45 prove") the program, since such changes may give 
different meaning to existing data variables, intro- 
duce new variables, or eliminate old variables-in such 
a way that processing 'old' data with the new program 
is apt to yield program dysfunction or incorrect and 

50 misleading results. 

Th^ allows the cell to be transmitted to another 
computer and executed there without concern for 
whether 

the dass-def ining program is available on the 
55 other computer; 

whether the reference dass-programs as 
found on the recipienfs computer are compatible with 
the data instances as built within the cell. 
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It is a feature of the invention that the logic of at 
least one of the associated class definitions may be 
uniquely identified in the stored cell by the hash of the 
associated program. This serves different purposes 
than storing the program definition itself: 

It allows cells to be stored in smaller space with- 
out duplicating the dass program in each cell, yet still 
insures exact integrity without storing an image of the 
program. This is accomplished during cell reload, 
when the actual hash is recomputed and compared 
with the expected hash. 

This insures that no software changes (deliber- 
ate, accidental, or malicious) can inadvertently lead to 
misexecution, yet it does not demand the storage 
overhead of duplicating copies of frequently used 
classes repeatedly in many cells. 

For commonly used classes, such as those which 
may be widely distributed through a given enterprise, 
it is reasonable to suppress transmission of the pro- 
gram itself-yet the hashes of the class programs are 
valuable to insure integrity by preventing a wrong 
class program from even being used. Whenever a 
class program is loaded, its hash is computed and 
compared with its expected value. 

If a cell does not contain the dass definition im- 
age, and there is no image available at reload that 
agrees with the hash, then the hash can be used to 
locate the conrect dass definition and to confirm cor- 
rectness when found. This strategy is effective even 
if the correct definition is recovered from offline, ar- 
chived storage. Once all the correct class definitions 
are recovered and made available online, then re- 
execution of the cell can commence. 

BRIEF DESCRIPTION OF THE DRAWINGS 

These and other features and advantages of the 
present invention will become more apparent in light 
of the detailed description of the following FIGURES 
of which: 

FIGURE 1 is a block diagram showing an exenr>- 
plary communication system which may be used in 
conjunction with the present invention. 

FIGURE 2 is a representation of the "cell block" 
data structure in accordance with an exemplary em- 
bodiment of the present invention. 

FIGURE 3 is a representation of a 'dass block" 
data structure in accordance with an exemplary enr>- 
bodiment of the present invention. 

FIGURE 4 is an exemplary "program block' data 
structure. 

FIGURE 5 is an exemplary "program structure' 
data structure. 

FIGURE 6 is an exemplary "execution block' data 
structure. 

FIGURE 7 is an exemplary "instance value' data 
structure. 

FIGURE 8A is an exemplary Variable block' data 
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structure, and FIGURE SB is an exemplary 'value 
Block" data structure. 

FIGURE 9 is an exemplary master area block 
data structure. 
5 FIGURE 10 is an exemplary "stored cell" as writ- 

ten to disk in accordance with an exemplary embodi- 
ment of the present Invention. 

FIGURES 11A through 11K are expanded data 
structures associated with the stored cell. 
10 FIGURE 12 is a general flowchart depicting the 

sequence of operations performed by the interpret- 
er/executor. 

FIGURE 13 is a flowchart delineating the se- 
quence of operations performed by the perform 
15 method routine referred to in conjunction with the 
flowchart FIGURE 12. 

FIGURE 14 is a flowchart delineating a sequence 
of operations in the create new instance subroutine. 
FIGURES 15A and 15B are flowcharts delineat- 
20 ing the sequence of operations in the load dass rou- 
tine. 

FIGURE 16 is a flowchart delineating the se- 
quence of operations and establishing a dass author- 
ization. 

25 FIGURE 17 is a flowchart delineating the se- 

quence of operations of the test class authorization 
routine which tests to insure compliance with the pro- 
gram authorization information. 

FIGURES ISA, 18B and 18C delineate the se- 

30 quence of operations perfonmed by the reload dass 
routine. 

FIGURE 19 is a flowchart delineating the se- 
quence of operations and the exit method function. 

FIGURE 20 is a flowchart delineating the se- 
35 quence of operations for the delete instance built-in 
function. 

FIGURE 21 is a flowchart delineating the se- 
quence of operations in the reset variable value rou- 
tine. 

40 FIGURE 22 is a flowchart delineating the se- 

quence of operations performed in deleting a current 
value. 

DETAILED DESCRIPTION OF THE PREFERRED 
45 EMBODIMENT 

FIGURE 1 is a block diagram showing an exenrv 
plary convnunication system which may be used in 
conjunction with the present invention. The system in- 

50 clud^ a communications channel 12 over which 
communication between terminals A, B,...N may take 
place. Communication channel 12 may, for example, 
be an unsecured communications channel such as a 
telephone line. Temiinals A, B....N may, by way of ex- 

55 ample only, be IBM-PC compatible computers having 
a processor (with main memory) 2, which is coupled 
to a conventional keyboard/CRT display 4. The proc- 
essor with main memory 2 b also coupled to a non- 
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volatile storage 7, which may be a disk memory. Each 
terminal A, B,...N also includes a conventional IBM- 
PC communications board (not shown) which, when 
coupled to a conventional modem (6, 8. 10, respec- 
tively), pennits a tenminal to transmit and receive 5 
messages including travelling programs. 

As used herein and as described in detail in the 
Travelling Program application Serial Number 
07/863,552. which has been incorporated herein by 
reference, a travelling program is a digital data struc- io 
ture which includes a sequence of instructions and 
associated data which has the capability of determin- 
ing atieast one next destination or recipient for receiv- 
ing the travelling program and for transmitting itself 
together with all relevant data detenmined by the pro- is 
gram to the next recipient or destination, an exenrv 
plary travelling program data structure is shown in 
FIGURE 2 of the Travelling Program Application. The 
data structures utilized during the execution of a trav- 
elling program and the software for executing the 20 
travelling program are describe din the Travelling Pro- 
gram Application and incorporated herein by refer- 
ence. 

Each terminal A, B. ...N Is capable of generating 
a message and performing whatever d igital signature 25 
operations may be required to load and execute the 
logic, data, and functions inherent within the travel- 
ling program in transmitting the message to other ter- 
minals connected to communications channel 12 (or 
to a communications network (not shown) which may 30 
be connected to comnnunication channel 12). The en- 
hanced digital signature and certification methodolo- 
gy described in the inventor's U.S. Patent Nos. 
4,868,877; 5,005,200 and 5,001,752 may be used 
herein, which patents are expressly incorporated 35 
herein by reference. Alternatively, more conventional 
digital signature methodologies may be utilized. 

This invention's enhancement of object-oriented 
programming techniques is particularly well suited 
and designed to facilitate the travelling program 40 
methodologies that are described in the applicant's 
allowed application 07/863.552. However, the pres- 
ent invention also significantly enhances the ability to 
efficiently generate applications programs and thus 
has great utility if only used in conjunction with a sin- 45 
gle computer user. 

The present invention utilizes discrete files, or 
electronic forms called "cells." These cells represent 
a package of objects which are essentially self con- 
tained and are a collection of instances whose execu- so 
tion can be suspended and stored as a file. A cell can 
be later reloaded (either by the same user or another) 
into main computer nr^mory where execution can be 
resumed at a then-designated method. 

In the presently preferred embodiment, data ss 
classes are defined in modified versions of the high- 
level programming languages, such as REXX. or the 
well known BASIC language. These languages have 



been converted from a procedural high-level pro- 
gramming language to the unique object-oriented ex- 
tension as described herein. The object-oriented ex- 
tensions to the high-level language provide ways to 
define a program's dass and specify the base class- 
es (if any) from which this dass is extended (by inher- 
itance) to define the various methods associated with 
a particular dass (for polymorphism) to distinguish 
the scope of program variables, and to easily create, 
invoke and process other objects instances. 

The cell may be viewed as a set of data, i.e., an 
electronic form that inherently indudes within it all the 
programs which are associated with that information 
and controls how to manipulate the information. With- 
in a cell may be collections of programs which may be 
treated as a single variable. For example, a cell may 
include a name and address field which would be an 
object that may have associated dasses. The asso- 
ciated program defines the various diverse opera- 
tions that may need to be done with the name and ad- 
dress fields. The variable, e.g.. address data, is 
bound to the cell and contains the programming infor- 
mation that knows the rules for manipulating it. so that 
at higher level the data may be handled only by refer- 
ence to the variable name without concern as to how 
to manage the underlying information. In this fashion, 
the overall system may be simplified leaving the conr)- 
plexity of processing to the individual objects. 

By identifying an instance as a variable, complex 
data structures induding programs, may be manipu- 
lated through an instance designator. An instance va- 
riable is a mechanism for referring to the entire object 
instance. 

The stored cell is a stoned file on disk. The stored 
cell is used to create an internal control block "cell- 
Block" as well as ancillary blocks which are used dur- 
ing execution by the operating system's interpret- 
er/executor. 

To better illustrate the manner of operation of the 
present invention, consider the task of writing a new 
income tax related object dass in accordance with the 
methodology of the present invention. The object 
class program will indude statements that call other 
already existing programs for accomplishing neces- 
sary tasks. 

In this example, the "cell" created may be viewed 
as an electronic fonm designed to handle income 
taxes. The program for performing the income tax cal- 
culations and form of generation may call existing In- 
come tax generating routines. Initially, the interpret- 
er/executor (l/E) ts directed to run the income tax 
class. Since the dass is only a progranvit is not a cell 
with existing data, the l/E compiles the dass (unless 
It is already pre-compiled into a p-code form), and 
proceeds to create a new cell. The program is com- 
piled and loaded into the n^in storage. The interpret- 
er then builds a dassBlock for the progranrts as will be 
described in detail below. The dass may, for exanv 
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pie. be defined in terms of generating a "Form 1040.° 
A routine in the interpreter creates a celt block for this 
initial instance of a dass, prepares it for execution, 
and performs the "Create" method of the "Fonm 1O40" 
class . 

During execution of methods In this dass, other 
classes may be invoked and new instances generated 
if there is a need to create further related forms in ad- 
dition to the Form 1040. The generation of an addi- 
tional form may cause yet another program to be 
brought into main storage necessary to generate the 
related instance. 

Due to the nature of income tax filings, there may 
be various a variety of dasses, each having various 
instances which need to be created. Each of such in- 
stances Is automatically handled by the methodology 
of the present invention. 

A function or "method" name may be treated dif- 
ferently by each of the related dass instances. For ex- 
ample, consider a request to determine the net in- 
come tax owed. For each of the associated dasses 
and instances, a different net income tax owed may 
be generated but only a single function request is nec- 
essary to gather such information. Each of the in- 
stances associated with a cell may compute the net 
income tax owed based on the methodology of which 
it is internally aware but which may be unknown to the 
higher-level D "Fonm 1040" main program class itself. 

Each of these instances may have associated 
completely different variables, but yet, at a higher lev- 
el, the program may use a single variable name, such 
as "net tax owed," to acquire all necessary informa- 
tion. All related programs which generate different 
forms are written into a cell upon the storage of the 
cell. The so-stored cell may then be readily electron- 
ically transmitted as a self-contained module to an ac- 
countant at a remote location. 

The accountant, upon receiving the stored and 
transmitted cell runs it with the interpreter/executor. 
It then determines that this is a cell, rather than a 
class, which is being executed or a cell is being exe- 
cuted. Since the cell has been executed and transmit- 
ted already exists, the executor causes the existing 
cell to be loaded into the accountant's computer's 
main memory as an internal control block data struc- 
ture identified as a 'cell block.' Other internal control 
blocks are also generated, as will be explained further 
below. 

Upon execution in the accountant's computer, the 
form-generating program will be executed in a "re- 
start' mode, as will be explained below. The routine 
executing in the accountant's system performs the 
processing necessary to display the appropriate tax 
forms for which the net tax owed was calculated. 

Prior to describing the presently preferred data 
structures, we first turn to some definitions and con- 
cepts which will be helpful in understanding the fol- 
lowing detailed description. 



In the described emt>odiment, each object 
CLASS is defined as a separate source definition 
(e.g., a separate file in a computer directory). Option- 
ally, it may be pre-compiled into a discrete p-code, 
5 which also remains as a discrete entity. It would be 
possible to indude several dasses within a single 
source or p-oode definition; although is not the case 
with the present embodiment, it is contemplated in the 
future. 

10 With either case, whether source or p-code, the 

CLASS definition may be digitally signed in order to 
Insure integrity or define explicit program authoriza- 
tion. Depending on implementation, it may be suffi- 
cient for the CLASS to be digitally signed and verif i- 

15 able by a particular public key or certificate, or to have 
a particular key or certification in the certification hi- 
erarchy. Alternatively, a more comprehensive 
scheme of authorization control could be employed 
such as described in inventor's Program Authoriza- 

20 tlon application Serial h4umber 07/883,868, which has 
been incorporated herein by reference. 

The described implementation is based on the 
REXX programming language-which is IBM's Sys- 
tem's Application Architecture (SAA) standard. In 

25 those aspects of the invention embodying a plurality 
of programming languages, the described implemen- 
tation uses the standard "BASIC" language. As indi- 
cated above, the standard language(s) is/are extend- 
ed with new programming constructs and new built- 

30 in functions to facilitate object-oriented programming 
according to this Invention. Obviously, this decision 
could be reversed, and other, or additional languages 
could be used. 

Some of the object oriented extensions include a 

35 new variety of data-object instance reference values. 
The REXX language defined only one variety of data: 
strings. These are subject to standard operations, in- 
cluding, e.g., assignment, concatenation, arithmetic. 
(Only strings reflecting numbers can be used in arith- 

40 metic operations). 

In the described embodiment, instance values 
are treated as fundamentally different than strings, 
and they are disallowed as being treated as normal 
string values (such as arithmetical or string oper- 

45 ends); however, they can appear, for example, in as- 
signment statements, as arguments and as paranrte- 
ters. It is certainly possible that in an alternative inrv 
plementatton of this invention, that whenever an in- 
stance value appeared where a string value was ex- 

50 pected, that thte would result in implidt invocation of 
a special (or default) method to that instance to gen- 
erate a string. Similarly, there are places where irv 
stance values appear and string values are generally 
disallowed-such as METHOD invocations. 

55 At any given time, a variable can contain its de- 

fault value (which, in REXX, Is generally the string val- 
ue of its name), a string value, or an instance value. 
A variable can be assigned different varieties of val- 
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ues at different times; this Is entirety flexible and de- 
pends solely on a program's logic. At each use, only 
the current value of the variable is effective. 

Variables assure instance value by assignment 
from "object" type built-in functions (such as "new/ 
"reload," etc.), other variables with instance values, 
other functions that review instance values, as para- 
meter values passed by a cabler, or, in the case of 
REXX, through the parse statement. 

In the preferred implementation, program vari- 
ables can belong to one of four different pools (con- 
ventional REXX and BASIC have no particular con- 
cept of such variable pools): 

GLOBAL-def ines variables associated with all in- 
stances in a particular cell. GLOBAL variables are ac- 
cessible to any instance (within the cell) from any 
class which declares this variable GLOBAL. Each cell 
has its own global pool. In the present embodiment of 
the invention, instances within a (sut>-)cell only have 
access to the global pool for that ceW-not of the super- 
cell. Nor does an instance properly contained within 
one cell have access to the global pools of subcells. 
Other embodiments of the invention could operate 
differently. 

SHARED-defines variables associated with a 
particular instance, but shared among all classes In 
the instance's lineage which declare this variable as 
SHARED. (Different Instances each have their own 
distinct occurrence of this variable). 

PRIVATE-associated with a particular instance. 
PRIVATE variables are accessible only to the in- 
stance and within the dass definition in which It is de- 
clared (and not accessible to other classes In the in- 
stance's lineage). Even different classes within the 
same lineage would have distinct occurrences of this 
variable. 

LOCAL-associated with a particular current exe- 
cution of a particular instance. LOCAL variables are 
undefined at the start of each method execution and 
are discarded when the method Is complete. If several 
Instances of the same Instance are concurrently ac- 
tive, then each has its own version of the local vari- 
ables. 

If a variable's pool is unspecified, then it is LO- 
CAL 

Variables can be explicitly discarded at any time 
by being dropped (REXX style), or having their value 
reassigned. However, each variable is also discarded 
when the particular object entity with which it is asso- 
ciated is d bearded. 

LOCAL variables are discarded after each meth- 
od execution. PRIVATE and SHARED variables are 
preserved across methods, but are discarded when 
the Instance is deleted or destroyed. GLOBAL vari- 
ables are discarded only when the cell Is deleted. 

Only GLOBAL variables are accessible by nrore 
than one instance. (Of course, values, including in- 
stances values, can be passed between instances as 



parameters and received as arguments). 

New object-oriented statements have been add- 

ed: 

CLASS-to explicitly specify the name of the data 
5 class being defined by this program and other char- 
acterbtics. 

GLOBAL-specifies variables from the GLOBAL 
pool. 

SHARED-specif ies variables to be shared within 
10 this instance among all the classes In the Inheritance 
hierarchy. A variable Is SHARED only between class- 
es in the same instance (hierarchy) which stipulate 
SHARED. 

PRIVATE-specifies variables in the PRIVATE 
15 pool. 

METHOD-specifles the beginning of. a method 
and the characteristics of the method. Including 
whether or not it is allowed to be entered for a given 
instance if other methods are already active for this 

20 Instance. 

In the preferred Implementation, each object in- 
stance is a composite data structure associated with 
up to 2+N different permanent data pools (where N is 
the number of class definitions in the Instance's dass 

25 lineage): the GLOBAL pool (for this cell), the 
SHARED pool (for the instance), and the N PRIVATE 
pools (for each class in the inheritance lineage asso- 
ciated with the pool's class). 

Further, when a particular method is active for an 

30 instance, there is the additional LOCAL pool associ- 
ated with that execution. Note that the preferred env 
bodiment pemnits the possibility that an instance may 
be subject to concurrent execution, even of the same 
method-in this case, there are unique LOCAL pools 

35 for each respective concurrence (however, the same 
PRIVATE, SHARED, and GLOBAL variables are used 
for all concurrences). 

FIGURE 2 is an exemplary representation of the 
"cell block" 11 data structure. The cell block 11 b the 

40 root of the cell as it is loaded in main memory 2 of FIG- 
URE 1 for execution. The cell block 11 Indudes a 
"next cell" field 12 which is a pointer to the next cell 
block which Is invoked by the subject cell block 11. 
Such a pointer is used when, for example, a Form 

45 1 040 generating cell block 11 invokes another cell for 
generating a state Income tax form which is to be ap- 
pended to the Federal Form 1 040 (and is automatical 
ly invoked when the 1040 cell Is executed). The next 
cell field may be used to link various cells together. 

50 There need not, of course, be an entry in the next cell 
field. 

The 'global pool" field 14 is a field which identi- 
fies the beginning of the pool of global variables 
which, as defined above, are variables assodated 
55 with all instance in a particular cell. For example, in 
the Income tax form generation example, the name 
variable may be a global variable applicable to all in- 
stances. Marital status may also be a global var^ble. 
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Cell block 11 also Includes a 'cell Identifier" field 
16 which identifies the cell by name and may indude 
a version number, if desired. The cell block 11 in- 
cludes a cell "face instance" field 18. The face in- 
stance field includes, as indicated In FIGURE 2, a 5 
pointer to the instance for handling outside requests 
to the cell. In the income tax example, if a query is 
made to the cell as to the net income tax owed, the 
face instance is responsible for responding to the re- 
quest by providing the desired result This may in- io 
volve inducing other instances within the cell. The 
face instance includes the program and associated 
data for controlling and handling requests/queries to 
the cell in its entirety. 

Cell block 11 also includes a pointers 19 to file is 
and certificate tags and a class table pointer to class- 
es for the cell (20) which identifies the programs as- 
sociated with the cell. Additionally, cell block 11 In- 
cludes a cell signature field 22, which is a pointer to 
the digital signature structure for the cell. This cell 20 
signature is the digital signature that was extracted 
when the cell was stored. After the cell block is load- 
ed, digital signatures are verified. The storage of the 
cell signature in cell block 11 permits display of the 
digital signatures upon request so that it can be de- 25 
termined who signed the cell. 

FIGURE 3 is an exemplary representation of 
"dass block" 23 internal control block data structure. 
A cell will typically have many dasses or program por- 
tions assodated therewith. For each program, there 30 
is a unique dassBlock data structure 23 created. 

In accordance with the presently preferred imple- 
I mentation, every class is associated with a single pro- 
gram. The first field in classBlock 23 is a dass link 
field 25 which is a link to other dass blocks in the cell. 35 
The next field is 'parent class" field 24. This field is a 
pointer to the classBlock from which the dass is ex- 
tended. A fundamental dass is a dass dependent on 
no other dass. However, other dasses may extend 
functions of the fundamental class and use its f unda- 40 
mental features. By way of example, only, such a fun- 
damental dass may be a program which builds a dis- 
play window rectangle, it functions to build a rectan- 
gle on a display screen having a particular height, 
width and color characteristics. 45 

A second dass may be built upon the rectangle 
class, e.g., a "button' dass, which utilizes all features 
of the window dass, but additionally includes a nunv 
ber of features or extensions. The button dass "inher- 
its' the features of the parent window redangle dass. so 

The number of levels field 26 defines the number 
of dasses involved in the lineage. In the prior exanrv 
ple, the number of dasses would be 2, e.g., the "but- 
ton" dass and the window rectangle dass. Class- 
Block 23 also Indudes a dass name field 28 which 55 
identifies the dass and a dass program field 30 
which is a pointer to the program block of the associ- 
ated program. The program block ts a list of all the pro- 



grams that are loaded. 

The dassBlock 23 also indudes a "method table" 
field 32 which is a pointer to the table of valid methods 
or fundlons which are used by the dass. Thus, the 
various operations or functions which are perform- 
able by the dass in question Is identified. Each entry 
in the method table for the dass has the format iden- 
tified in field 32 in FIGURE 3. 

When a program to be executed is compiled, it is 
broken down into p-code so that it can be executed 
more rapidly. The method entry table 32 provides an 
identification as to where the p-code starts for the 
particular method of the associated class program. 
Thus, when a particular instance is executing and re- 
quires one of the valid methods to be performed, the 
method may be accessed and executed eff idently at 
high speed. 

As shown in FIGURE 3, each method entry in- 
cludes a mechanism for linking to other related meth- 
ods in the table. This may be done in a variety of fash- 
ions, including, for example, the use of the B-tree. 
The table also indudes a pointer to the classBlock as- 
sociated with the definition of the method sought to 
be performed. For example, the dass window rectan- 
gle may contain the definition of the method which is 
to be performed in the "button" dass. 

The method table also stores an offeet defining 
the start of the p-code for the method in the associ- 
ated dass. Additional method table entries indude 
the length of the method name and the name of the 
method field. 

The class authorization field 34 is a pointer to the 
authenticated authorization structure which defines 
those operations which are permitted to be per- 
formed in accordance with the applicant's copending 
program authorization information application Serial 
Number 07/863,552. The classBlock 23 also indudes 
an indication of the lowest and highest levels of pro- 
grams making processable instances. 

FIGURE 4 is an exemplary data structure for the 
"program block" internal control block 37. The pro- 
gram block field Identifies where the program is locat- 
ed at the time of its current execution, among other 
information. The program block data structure 37 in- 
cludes a "next program" field 38, which Is a pointer to 
the next program block invoked by the subject pro- 
gram. It provides a mechanism for linking related pro- 
grams together. The program block data structure 37 
also indudes a program infonmation field 39 which is 
a pointer to the program identification element. Field 
42 defines the size of the p-code program which Is 
stored and block 37. Also induded in the program 
block Is a "type of program" field 44 that Identifies the 
program's language. 

Fields 46 and 48 include the hashes of the source 
and compiled p-oode versions of the program, re- 
spectively. These fields may be used to ensuro that 
two programs having the same name can be distin- 
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guished. Additionally, the hashes may be used for 
verifying digital signatures for the program. The pro- 
gram t>lock 37 also indudes a class count field which 
identifies the number of classes referencing the pro- 
gram block, a program usage field 50 which is a poln- 5 
ter to the program structure control block and a poin- 
ter to the source code. Field 51 is a pointer to authen- 
ticated authorization structures which are structured 
in accordance with the applicant's Program Authori- 
zation Infonmation application. io 

FIGURE 5 is an exemplary "program structure" 
control block 52. Whereas the program control block 
37 includes fields some of which may vary, the 'pro- 
gram structure" fields are constant regardless of the 
platform which is executing the program, and is the is 
form or the p-code if it is stored on disk. 

"Program structure" control block 52 includes 53 
which identifies the size of the program structure 
field 54 which is a 'program identifier" and stores the 
name used to identify a particular program. The pro- 20 
gram structure block also includes a field 56 identi- 
fying the list of methods and dass names associated 
with the program and the associated p-code offeets 
for identifying the start of the p-code for the associ- 
ated method. The "program structure" block 52 also 25 
i ndudes a "variable tables" field 58 and a table of con- 
stants field 60. 

The program structuro block 52 also includes, as 
shown in FIGURE 5. the p-code instructions 61 of the 
program. 30 

FIGURE 6 is an exemplary "execution" internal 
control block 62. The execution control block 82 
keeps track of the cun-ent state of the execution proc- 
ess. The execution control block 62 includes a next in- 
struction field 64 which is a pointer to the next p-code 35 
instruction. 

Executk>n control block 62 also indudes a ^'dass 
pointer" field 66 which points to the associated class- 
Block. An instance execution field 88 points to the 
particular Instance being executed and a local pool 40 
field 70 points to the pool for local variables. Before 
the method starts, there will be no local variables. As 
the program executes, local variables are stored in a 
scratch pad type memory and the execution block 
points to where those local variables reside. The exe- 45 
cution block 62 also indudes a "provious execution 
block" field 72 which points to the previous execution 
block which was under control prior to the current exe- 
cution block being processed. 

There are likely to be additional fields in this block so 
to accontmodate details, such as those outlined in ap- 
plicant's Travelling Program Application, conceived 
with other aspeds of execution which are not neces- 
sarily unique to this invention (such as do blocks, pro- 
cedures blocks, etc.) 55 

FIGURE 7 is an exemplary "instance value' data 
structure 73. An instance is particular data with a pro- 
gram bound thereto as an object For example, an in- 



stance may be the data for a particular income tax 
form tx>und to a program which determines the net tax 
owed. 

The "instance value" data structure 73 indudes 
a "dass reference" field 74, which points to a partic- 
ular dass program for handling the instance values in 
data structure 73. Data structure 73 also indudes a 
"cell reference" field 76, which points to a particular 
cell block for the instance (in case more than one cell 
is involved). Instance value structure 73 also includes 
a pending delete field 78 which is used to delete an 
instance after it has been executed. 

Instance value data structure 73 also includes an 
"execution count" field 80 which identifies the num- 
ber of active execution blocks for this instance, a scan 
indicator field 81 idendfying a particular "save" oper- 
ation (see description of FIGURE 1 0), and a use count 
field 82 which identifies the number of pointers to this 
block induding variables and the face instance. If no 
pointera point to this control block, then it may be an 
indication that the data structure should be deleted. 

The data structure 73 indudes a "level counf 
field 84 that identifies the number of levels in the as- 
sociated dassBlock which indicates the levels of in- 
herited features as previously described in conjunc- 
tion with FIGURE 3. Data structure 73 also includes 
a "shared pool" field 86 which points to the memory 
head of the shared variables. This mechanism allows 
data to be shared among the programs within a given 
instance's dass lineage. Data structure 73 also in- 
cludes a private pool field 88 having the fonmat shown 
in FIGURE 7. Private pool fields relate to private va- 
riables only assodated with a particular dass within 
an instance's lineage. 

FIGURE 8A is an exemplary "variable block" data 
structure 90. Variable block data structure 90 in- 
cludes a "link variable" field 92 which is a linkage to 
another variable block In the same variable pool in the 
system. Field 93 is a pointer to a value block which 
gives the variable's value. Field 94 identifies a pool 
head for qualified variables. The length of the variable 
name and the variable name are specified in fields 95 
and 96, respectively. FIGURE 8B is an exemplary val- 
ue block data structure 97 which identifies the value 
of the variable. The data structure 97 indudes a value 
type field 98 which identifies the variable as a string 
or instance. The data structure indudes entries for 
strings (99) and instances (100) as shown in FIGURE 
8B. 

FIGURE 9 is an exemplary master area block 
data structure 101. The master area block contains 
overall system information and includes a number of 
pointers such as 'maincell' 98 which points to the cell 
block for the primary cell, message reference 99 
which points to the message reference table, program 
table 100 whteh points to the table of all loaded pro- 
grams, 'exec stack" 101 which points to the latest 
exec block in the executbn stack, and pointers 106, 
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107 to the list of attached files and the certificate 
cache list. 

. FIGURE 10 shows a •stored cell" 11 as written to 
disk in accordance with an exemplary emt)odimentof 
the present invention. The data format which is creat- 5 
ed and written to disk may be generated by a built-in 
function which Is invoked from within a dass program 
to save the current state of a cell (either the current 
cell or an associated cell). 

Save can also be invoked from "outside" the cell, io 
as an "environmental" function supplied to the user by 
the interpreter/execute r-such as a "save" option on 
"pull-down" file action-bar field. 

Storing a ceil is done in at least two phases: the 
first phase is a "marking" phase in which is deter- is 
mined the set of all structural constituents that are to 
be stored. This includes the cells (subcells), variable 
pools, variables, values, instances, etc. In the present 
embodiment, neither local variables nor the current 
execution task structure (i.e., the active methods as 20 
represented by execBlocks) are saved as part of the 
cell. The is in accord with the strategy that, as part of 
restoration, the face cell is executed at its instance's 
"restart" method. 

Programs using the "save" function must keep 25 
this special aspect in mind. The alternate approach, 
where the entire execution stack is saved In the cell, 
together with the transient (local) variables is also 
feasible and only requires slight addition of the cur- 
rent process: in which a structure representing the Io- 30 
cal stack (including the associated local transient va- 
riable pools) of all active methods is also saved in the 
cell. Such an approach is similar to that described in 
inventor's travelling-program invention application 
and has similar considerations. 35 

During the first scan phase, the special "toBe- 
Saved' methods are Invoked (for those instances 
whose classes have them) in order to perform ancil- 
lary processing that may be needed to accommodate 
eventual smooth "restoration" operation. Such ancil- 40 
lary processing includes, for example: extracting cur- 
rent information which may not be immediately known 
to the celt from visual objects (such as perhaps, in- 
complete input field data). It is expected that most in- 
stances will have no special requirements since the 45 
state of most instances depends only on the values of 
interna] persistent variables-which are automatically 
saved. It is incumbent on "toBeSaved" methods not to 
invoke or significantly alter the state of other active 
instances-sin ce such instances may have already so 
had their own "toBeSaved" methods driven. 

After the "toBeSaved" method is driven for each 
instance, its variables (any in the private and shared 
pools, as well as any global variables which are ref- 
erence, or whbh belong to STEMs which are refer- ss 
enced) are examined and instances defined therein 
which have not been scanned are then so scheduled 
and nnarked with the serial number of the current save 



request, so that each instance will be scheduled pre- 
cisely once.The scan starts with the face instance of 
the cell to be saved and proceeds recursively through 
all the (instance) variables which are then encoun- 
tered. 

Whatever instance is specified to the save func- 
tion becomes the face instance of the resulting saved 
cell. If, in analyzing the related variables during the 
scan phase, it is determined that instances in other 
cells are referenced, then those ceils are included as 
sub-cells in the new stored cell being created. It is 
possible in this way for the original main cell to be- 
come a subcell of one of its former subcelts, and the 
former subcell to be the new main cell. This typically 
occurs when cells have inter-linking pointer variables. 

The second scan phase then collects the aggre- 
gate set of variables and values which were marked 
in the first scan, and emits the stored cell (file) struc- 
ture therefrom. 

Depending the options specified as part of the 
save request, all, some or none of the object dass 
program definitions may be saved as part of the file. 
These are saved in either source or compiled form (or 
both), together with whatever authenticating or au- 
thorizing digital signature(s) structure(s) may have 
been encountered. 

The saved data is separated into two portions: 
that which Is essential to cell authentication, and that 
which is not. In this case, authentication is used to 
digitally sign the information necessary to assure ac- 
curate reconstruction of the cell when execution re- 
sumes after RESTORE, information which is not es- 
sential, such as the image of class programs thenv 
selves is not signed, since such information is consid- 
ered to be a "convenience" which can be added or 
omitted without impairing security. However, the 
identification of the varbus class programs, usually 
together with their hash is important, since it is used 
to insure that the correct classes are actually used. By 
allowing optional inclusion of the class programs in a 
cell, the cell can be stored in the most optimal way for 
its intended use. 

The celt may also include additional data struc- 
tures. In the described implementation, there are two 
such sets of additional Information: certificates and 
external f iles-which are specifically incorporated and 
need to be bound to the cell. 

The list of digital signature certificates Is called 
the "common certificate cache." These certificates 
are associated digital signatures performed on at 
least three different classes of data structures: 

• class program definitions (for authentication 
and/or authorization). 

• data within instances which has been authen- 
ticated or authorized as part of program execu- 
tion (for example, an ANSI X12 850 Purchase 
Order transaction set). These signatures are 
solicited by program logic Itself on constructed 
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data, and the certificates may be explicitly 
relegated to the common certificate cache. 

• the body of the cell which is authenticated dur- 
ing transmesion. 

Combining the certificates into the "common cer- 5 
tif icate cache" allows certificates to be carried within 
the cell without duplication. Duplication is likely to oc- 
cur because, for example, different object program 
classes are often authorized by common trust 
agents; and many different data signatures may be io 
signed by a single user, or by users dose together in 
the certification hierarchy (and therefore having 
many common certificates). 

By being located within the unauthenticated por- 
tion of the cell, certificates can be added or excised is 
as the usage of the cell becomes evident. For exann- 
ple, a cell destined for short term local storage may 
not need to have embedded certificates, since this 
wastes storage with excessive duplication. However, 
it becomes reasonable to embed the certificates in 20 
the cell if it moved to long-term archive, or if it is being 
transmitted to other users (who may not have all rel- 
evant certificates in their cache). 

Maintaining a single cache of certificates for a 
stored cell requires that the various certificated ele- 25 
ments maintain use counts. To this end, each (sub- 
)cell contains the summary of certificates it requires, 
which requires that data signature have its certifi- 
cates presented for cache insertion when the signa- 
ture is created or received, and for cache excision 30 
when the signature value is released or becomes use- 
less. Similar use counts are kept for signatures be- 
longing to class programs, and even the cell itself. 
Each certificate summary consists of little more than 
the hash of the certificate the use count(s). 35 

Another category of embedded data includes "ex- 
ternal" data files which have been attached to the 
cell. The motivation and mechan ism for doing this are 
described in detail in the Travelling Program Applica- 
tion. However, with multiple cells, it is desirable to also 40 
maintain indicators as to which (sub-)cells are using 
the various files, in case some subcells are "broken 
out" and saved as their own separate stored-cell en- 
tity. 

With respect to storing a cell, it is Important to 45 
scan and mark everything to be stored, including the 
face instance value and the global pool. For pools, 
scan and mark all the variables in the pool. For vari- 
ables, scan and mark all the values and sub-variables 
associated with the variable. Subvariables occur with- so 
in "REXX" as constituents of a stem variable. 

With respect to values, indicate the value has 
been seen during this store process for string values. 
For instance values, indicate the value has been seen 
during this store and invoke the "toBeStored" method ss 
for the classes associated with this instance (use 
same multiple method approach with "priority" con- 
sideration as method approach with the "new" meth- 



od for create as described elsewhere). Mark the dass 
associated with this instance; scan and mark the 
shared pool and the private pool associated with each 
class in the instance's dass lineage. 

For classes, mark the dass program definition, 
including any digitally signed (or otherwise imputed) 
authorization or authentication and scan and mark 
the class's base dass(es), if any. 

For storing items marked, in the case of dasses, 
the hash of the source and/or p-code (as appropriate 
or specified in the current circumstance) is always 
stored. It is also possible that either the image of the 
source code or the p-code, or both, may be stored, but 
these are preferably stored in the portion of the ceil 
which is not subject to overall authentication. 

Also stored is the level of the interpreter/executor, 
and the level of the application version of each of the 
class progran^. This allows the possibility of future 
substitution of an enhanced/corrected replacement 
class provided the replacement is functionally consis- 
tent with the data in the existing instance. 

It is often desirable to also store any digital sig- 
natures, certification and/or authorization that may 
be associated with a class-and, depending on the op- 
tions spedf led and the goal of the particular emt>odh 
ment, it may be appropriate to store this in either the 
authenticated or the unauthenticated portion of the 
stored cell. 

Also, in keeping with the inventor's above- 
identified Travelling Program Application which has 
been Incorporated herein by reference, it may be de- 
sirable to also store copies of various other files as 
part of the stored cell. 

As the final step in storing the cell, and if required 
by the Implementation or the save options, then the 
critical "authenticated" portion of the cell is digitally 
signed. 

To mail a travelling object-oriented program: mail 
an image of the stored cell (as would be created by 
"storing a cell." If it Is known that (all) the redptent(s) 
possess a given dass definition, then it need not be 
included in the stored (and mailed) image (this allows 
a smaller transmitted image); otherwise, the conser- 
vative course of action is to indude the source code, 
the p-code, or both (induding the source code allows 
a different version of the interpreter/executor to rein- 
terpret the dass-which is useful if different versions 
of the Interpreter^executor have incompatible p-co- 
des). 

Turning back to FIGURE 10, the stored cell 111 
on disk includes a cell identification field 112 which 
identifies the cell. For example, the cell identification 
provides the name, e.g., Purchase Order for Corpor- 
atk)n X, which permits a program to scan a file and 
pull up the file name to access the cell. 

As indicated at 114 in FIGURE 10. all the material 
which follows, nrtay if desired be encrypted and stored 
in compressed form the specific programs assodated 
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with the cell are stored in in field 15 on disk (including, 
e.g., dass program 1, 2, ...P). 

As indicated at label 116 in FIGURE 10, the ma- 
terial which follows in the stored cell nnay be optionally 
authenticated. Thus, once this material is stored in 
the cell, it cannot be altered without affecting the ap- 
parent integrity of the material. 

Field 117 includes a set of "program reference 
vectors" from program reference 1 through program 
reference N. In this fashion, instead of storing the en- 
tire program on disk, an unambiguous reference to 
the program may alternatively be utilized such that 
the program may be later accessed as desired. The 
"program reference vector" 117 unambiguously iden- 
tifies each cell program, such that if necessary it may 
be accessed from a program library. 

Cell (and subcell) vector field 118 defines the 
main cell stored, as well as all sut>-cells if more than 
one cell is associated with the file, where one main 
cell has absorbed other subcells. The "data file vec- 
tor" field 120 includes data file specifications for va- 
rious files which may be carried with the program 
when used in travelling program applications in accor- 
dance with above-identified travelling program meth- 
odology. 

The "authenticating signature" field 122 is used 
to store signatures associated with the signature au- 
thenticated material defining the program cell, if it is 
desired to be authenticated. Finally, field 123 stores 
a certificate specification set for maintaining any cer- 
tificates used in digital signature processes. 

FIGURES 11 A through 11 K are expanded data 
structures showing stored cell porttons in further de- 
tail. Program data structure 124 shown in FIGURE 
11A is an exploded view of the class program 1-P 
fields shown in FIGURE 10. The first field in the pro- 
gram data structure 124 is the "program date" field 
126, which may define the date the program was 
made or compiled. 

The program identifier field 128 Is the name as- 
sociated with the program. The "program Identifier" 
128 is expanded in FIGURE 11 B and will be described 
further below. 

The 'program executable" field 130 specifies 
whether the program is executable in source code, p- 
code or both and uses program mode field 132 to 
specify whether the program may be executed in 
source code or p-code. 

The program itself is resident In the executable 
image field 133 shown in FIGURE 11 A in source or p- 
code. The program structure is in the format as spe- 
cified In FIGURE 5, described above. In field 134, a 
possible second executable image of the program is 
stored if both source and p-code have been speci- 
fied. Program authorization information and a digital 
signature of program Identifier is stored in field 136. 
As mentioned previously, the program authorization 
information is utilized in accordance with the appli- 



canfs copending program authorization information 
patent application, which has been incorporated here- 
in by reference. 

The program identifier structure 128 identifies 

5 the programming type (field 138) by identifying the 
programming language. 

Field 140 identifies a program X209 assigned 
object identifier, which is an identifier in accordance 
with the X.209 protocol which uniquely identifies the 

10 program in accordance with accepted standards. A 
program name field 142 identifies the specific pro- 
gram by name for display to the user 

Program Revision level field 144 identifies the 
program's revision level. Compatibility field 146 iden- 

15 tifies the extent to which the program is compatible 
with data produced by other revisions from the lowest 
program revision producing compatible data to the 
highest program revision producing compatible data. 
Typically, one imagines the highest revision level will 

20 equal that of the current revision. However, if it antici- 
pated that the current private, shared and global va- 
riables will be "upward" compatible with future releas- 
es, then planned future revision levels can be set 
aside. The program identifier structure 128 also in- 

25 etudes a hash of the source program field 148 and 
hash of the p-code program field 150. 

The "program reference" structure 151 is a blow 
up of the program reference information shown in 
FIGURE 10 and includes the program identifier field 

30 128, described above in FIGURE 11B. Additionally, 
the "integer field" 152 of the parent class program 
identifies the version of the parent class program 
which ts referenced as compatible in embodiments 
where more than one class is allowed per program, 

35 then this field must be moved to a new structure de- 
fined for each dass. 

FIGURE 11 D Is an exemplary cell data structure 
118 expanding the corresponding cell of presentation 
in FIGURE 10. Cell identifier 156 identifies the cell 

40 and is described further below in conjunction with Fig- 
ure 11G which shows an exploded version of the cell 
identifier. 

The "instance vector" field 158 has one entry for 
each Instance associated with the cell. The first entry 

45 is taken to be the face instance for this cell. Field 160 
defines the index (within the Program Reference Vec- 
tor) defining the program containing the dass asso- 
ciated with this instance. Field 162 identifies which 
class within the program (identified in 160). In the cur- 

50 rent embodiment with only one dass per program, 
this field Is superfluous and always indicates the first 
class. Instance field 164 defines the shared variables 
within the instance. Field 166 Is the vector of private 
variable pools associated with dass in the instance's 

55 lineage. Field 167 defines the private pool for the fun- 
damental (eldest) dass; while field 170 defines the 
private pool for the most extended (youngest) dass in 
the instance's lineage. 
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Cell data structure 118 additionally includes a 
global variable pool field 172. Additionally, the celt 
118 includes a data file tag reference field 174 which 
relates to the attaching of data files when the present 
invention is used In a travelling program context in ac- 5 
cordance with the travelling program related applica- 
tion identified above. This data file tag field 174 
keeps track of which cell has an associated attached 
data file. Certificates field 176 references the certif- 
icates which are referenced with the particular (sub- io 
)cell 118. 

FIGURE 1 1E is a generic representation of the 
variable pool data structure 178 which includes vari- 
ables 1, 2, to the last variable in the pool (fields 179 
through 181). The structure may be utilized in con- is 
junction with either a shared variable pool, a private 
variable pool, or a global variable pool. 

The variables structure 182 is identified as 
shown in FIGURE 11 F. The variable data structure 
1 82 includes the variable name 1 83 to identify the va- 20 
riable and includes a variable value field 184. In ac- 
cordance with the present invention, variables may 
have strings or instances as values. The variable val- 
ue field is represented in X.209 representation within 
the stored cell. The X209 data type used to define the 25 
type of the value: if the stored value is an X.209 OC- 
TET type, then this is a string value and directly rep- 
resents the variable's value. If the stored value is an 
X.209 integer type, then this is taken to represent the 
instance indexed in the cell's instance vector (field 30 
158) by the integer value. If the stored value is an 
X.209 sequence type, this is taken to be an instance 
in a different (sub)cell, wherein the first integer in the 
sequence defines the instance in the 158 instance 
vector associated with the cell indexed in the cell vec- 35 
tor 118 using the second Integer of the sequence. If 
the variable is a simple variable (not a stem) or a stem 
with no qualified variables, and the variable has no 
assigned value, then it is omitted from the pool. How- 
ever, if it is a stem with qualifications but no assigned 40 
value, then it is included, however, the stored value is 
represented as an X.209 null primitive. 

FIGURE 11G shows an exploded view of cell 
identifier 1 56 of the cell data structure shown in FIG- 
URE 11 D. The cell identifier 1 56 includes a cell format 45 
code field 186 which Is used to distinguish old formats 
from current formats. The "moment of construction" 
field 187 defines the time the cell was built 

Field 188 is used to identify the cell category us- 
ing an X209 object identifier and may, for example, so 
be used to identify the cell category as relating to in- 
come tax form generation. The cell category is des- 
ignated by name in field 189. Cell instance identifier 
field 190 may be used to further identify the instance 
with respect to the individual cell, e.g., to generate the 55 
net tax oyNed for a particular indh/iduaL The fields 190 
through 196 provide further cell identifying details 
with respect to identifying the instance's name, title 



and various qualifiers as needed for a particular ap- 
plication. 

FIGURE 11 H is an exemplary data file specifica- 
tion data structure 198. This data file specification 
data structure 198 is useful particularly in a travel- 
ling-prt^ram context in accordance with the method- 
ology of the inventor's atxjve-identlfled copending 
travelling program related application in which data 
files are, for example, attached to a travelling pro- 
gram. Use count field 200 identifies the number of 
cells which use the identified data file. Data type field 
202 identifies the nature of the data contained in the 
file so as to denote whether the file is a record, bit- 
stream, or other type of file. File content field 204 is 
used to describe with more specificity the nature of 
the file and its constituent records. 

FIGURE 111 shows an exemplary file tag data 
structure 174 and is an exploded view of field 174 in 
FIGURE 11D. The "attach identifier" field 206 Is a 
data string that identifies the file which has been at- 
tached in accordance with the travelling program 
methodology described in the applicant's copending 
application. The data file reference field 208 is an in- 
dex to the data file specification data structure 198 
shown in FIGURE 11H. The '*lag use count" field 210 
defines the number of attached file requests that 
have emanated from the subject cell. 

FIGURE 11J is an exemplary certificate specifi- 
cation data structure 123 which is an exploded view 
of the "certificate specification" field of FIGURE 10. 
The certificate specification data structure 123 in- 
cludes a copy of each certificate used for digital sig- 
nature operations for use in various digital signature 
contexts. One use of digital certificates in the present 
system is to sign individual programs to give those 
programs authority to perform various transactions. 
Such digital signatures may be performed in accor- 
dance with the applicant's enhanced digital signature 
methodology as described in U.S. Patent Nos. 
5,005.200; 4,868,877; and 5,001 , 752. Another use for 
digital signatures and associated certificates is to 
have the program sign data with which it is associated 
as per Travelling Program Patent application. Adigital 
certificate Is also useful in operations involving sign- 
ing the overall cell, particularly where the overall cell 
will be transported from one user to another via the 
applicant's travelling program methodology. 

The use count field 212 specifies the number of 
references to the certificate. The use count field may 
also indude the tag use count in each cell or subcell, 
the signatures on signed variables and the references 
by other certificates in the certificate specification 
cache. All certificates used in the cell may be stored 
in this common certificate cache menrwy. An "iden- 
tifying hash" certificate field 214 and the certificate 
itself in field 216. 

An exemplary "certificate tag" data structure 1 76 
Is shown in FIGURE 11 K. The structure Is used where 



15 



29 



EP 0 638 860 A2 



30 



cells are embedded in other cells to keep track of the 
certificate usage in such embedded cells. The certif- 
icate tag data structure includes an "identifying hash 
of the certificate" field 218 and a "tag use count" field 
220 to identify the number of uses within the subject 5 
celt. 

The preferred embodinnent of the invention ac- 
cepts either the REXX (or BASIC, alternatively) 
source as the definition of an object class, or as cono- 
piled p-code. Whenever a previously unseen object io 
class is encountered, its source code is compiled (dy- 
namically) into p-code within the computer memory. 

FIGURE 12 is a general flowchart depicting the 
sequence of operations performed by the interpret- 
er/executor. Initially, the interpreter/executor is load- is 
ed by the underlying computer operating system. It 
creates a master control area as shown in FIGURE 9. 
Either as part of invocation or immediately thereafter, 
the interpreter determines whether initial execution is 
directed toward a class definition or an existing cell. 20 
This knowledge may be embodied in the execution re- 
quest or may be solicited from the user. For example, 
it could be an explicit parameter or it could be deter- 
mined from the initial file name. 

If a dass is to be executed, then this implies that 25 
a new cell is being created. The interpreter creates a 
control block for the active cell and loads the dass lin- 
eage hierarchy (as described in more detail later). The 
instance for this dass is created. This instance be- 
comes the "face" dass for the cell. The "create" meth- 30 
od is then invoked for this instance. 

If an existing cell is to be executed, then this cell 
is "reloaded" (as described elsewhere), so that all 
constituent variables, values, program classes, and 
embedded sub-instances, etc.. are reconstituted into 35 
executable state. Then the face instance is invoked 
using the "restart" method. 

In the preferred embodiment, it is incumbent on 
the face instance, whether by the "new" or "refresh" 
to interfece with the environment (such as "Win- 4C 
dows") so that further activity will be recognized. 
Such interfacing is done by invoking various func- 
tions and routines (such as may be buitt-into the in- 
terpreter or linked dynamically) to establish and pre- 
pare for interaction with the "environment"-e.g.. dis- 45 
played graphical objects, timers, other cells, other 
programs, databases, etc. 

One of the chores of such interface function in 
the interpreter/executor, whether initially or during the 
natural progression of execution, Is to maintain a ta- so 
ble of external identifiers, so that incoming messages 
generated to the interpreter from external entities are 
properly notched to internal instances and methods. 
This table is maintained by functions driven by vari- 
ous dasses. 55 

In some cases, the initial method execution asso- 
ciated with the new or reload request ("create" or "re- 
start," respectively) may be signal that this is all that 



is needed-that there is no need for further additional 
processing. If ths is the case, then the interpreter will 
have been so notified (that no further environment in- 
teractbn is expected) and will undertake termination 
processing through the use of special "built-in" func- 
tions. 

Otherwise, in the normal case, operation is driv- 
en through receipt by the interpreter/executor of mes- 
sages generated by the environment (such as Win- 
dows), timers, devices, or other programs-induding 
other celts. 

When a message is received or encountered by 
the executor, it is matched to a table that assodates 
instances and methods with incoming message iden- 
tifiers. The instance is then activated using the indi- 
cated method. When the associated instance returns 
from the invoked method, the executor repeats its 
wait for a further message. This loop continues until 
the cell indicates that it is complete and should be ter- 
minated. Such indication is made with a termination 
built-in function. 

Turning spedf ically to FIGURE 12, when the in- 
terpreter/executor begins execution, initially it must 
be determined whether the system is executing a 
class or a celt (302). Upon initial execution, a program 
(class) may be executing to create a cell and its data 
or the system may be dealing with an existing cell al- 
ready having its programs and data packaged togeth- 
er as described above. 

If the check at block 302 reveals that a cell is be- 
ing executed, then the routine branches to block 312 
in which a "loadCell" function is called based upon a 
specified cell name. The load cell routine operates to 
verify the digital signatures, if any, that have beenai>- 
plied to the cell. In most cases, the signatures are 
used to indicate that the cell has not been tampered 
with since it was stored. When the cell is stored again, 
it will be different and the current signature will be 
moot. 

It is noted that within a cell, digrtat signatures can 
also be performed on various data elements, or struc- 
tures, to insure their unchanging integrity across an 
unlimited number of cell executions but their further 
verification is a matter controlled by the dass pro- 
grams. In the loadCell built-in function, the signature 
data is verified for class definition programs operat- 
ing in connection with various instances. In the load- 
Cell routine, a new cell block is created to maintain all 
new pointers. A call is made to the reload dass routine 
to be described below for alt classes. Classes are 
stored in lineage order so that every extension dass 
follows its associated base. Thereafter, a restore pool 
routine is executed for global variables and a restore 
instance routine for the face and other instances. The 
pointer to the face instance is stored in the cell block 
as previously described. Once the instances are es- 
tablished, all variations that reference instances are 
updated with the final pointers. 
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Thereafter, the loadCell routine operates to drive 
the restart method for ail Instances which have this 
method. The routine only drives the restart once for 
each instance. This is controlled with flags in each in- 
stance block. Initially, the routine starts with the face 5 
instance. Instances can drive the restart method in 
other presunnably related instances. For Instances 
with restart methods which are not driven explicitly by 
other instances restart will be automatically driven af- 
ter any explicit invocations. This is controlled by a flag io 
within the instance's specification. For each Instance, 
the order in which possibly multiple restart requests 
are driven is handled with the priority operand on the 
class field just as it is for the "createNew" routine to 
be described below. is 

In the loadCeil block 312. a cunrentcell is loaded. 
The cell which has been loaded in block 312 is saved 
as the primary cell. In block 304, a new cell block Is 
created as the main or primary cell. The new instance 
is saved as the face instance to the prinriary cell. The 20 
manner in which a new instance is created will be de- 
scribed further below. 

Whether a new cell has been created in block 304 
or an existing cell has been loaded, as the routine en- 
ters block 330, a cell has been loaded into storage. 25 
The loop labeled "dispatcher loop" denotes the actual 
running of the programs associated with the cell. 

In block 330, a check is made to determine wheth- 
er termination has been requested. If termination has 
been requested, then the routine branches to block 30 
340, in which termination operations, including per- 
forming a discard method of the face instance of the 
main cell to delete an operation, which deletes the cell 
block structure and the executor is exited. 

If the check in block 330 reveals that there has not 35 
been a termination, then processing continues at 
block 332, where the first incoming message is re- 
trieved. On subsequent passes through this loop, the 
next incoming message is retrieved. A "message ref- 
erence table" is accessed to determine which in- 4o 
stance is to be associated with the incoming mes- 
sage. If no associated instance is found, then the 
message is discarded, and a possible diagnostic 
message is issued and the routine branches back to 
the beginning of the dispatcher loop at block 330. 45 

Presuming that the reference table specifies an 
instance, that instance is then invoked. The specified 
method of the Instance is then performed using the in- 
coming message fields as a parameter. The manner 
in which the method Is performed is described below so 
in further detail in conjunction with FIGURE 1 3. After 
the method is performed in accordance with FIGURE 
13, the message is then discarded (336) and the rou- 
tine branches back to block 330 to reenter the dis- 
patcher loop. 55 

FIGURE 13 is a flowchart delineating the se- 
quence of operations performed by the "perform 
method' routine referred to in conjunction with the 



flowchart FIGURE 12. The "perform method" flow- 
chart is repeatedly executed. The routine takes a par- 
ticular instance, which is treated in this system as a 
variable supplied as "instance indicator", and per- 
forms a particular method with it using supplied input 
parameters. In effect, the perform method routine op- 
erates as a variably named subroutine. 

In accordance with block 402, if the "instance in- 
dicator" is an instance value, then that operation on 
the "instance value" data is performed using the iden- 
tified method based on identified parameters (404). 
In block 404, the real instance is set to equal the in- 
stance indicator and the class level is set to equal the 
youngest (highest) dass level associated with the in- 
stance's dass. Thereafter, the routine branches to 
the "find method" portion of the routine at block 420. 

If the instance indicator is not an instance value 
then a check is made at block 406 to see if the in- 
stance indicator is a special string value "." The "." 
special string value indicates that the currently exe- 
cuting instance is performed with the input parame- 
ters. If the instance indicator does equal the special 
string value then the real instance variable is set 
equal to the currently executing instance and the 
class level is set to equal the class level in the cun'ent- 
ly executing instance as derived from the execution 
block shown in FIGURE 6. The routine then branches 
to the find method processing beginning at block 420. 

If the instance indicator check in block 406 is neg- 
ative, then a check is made in block 410 to see if the 
instance indicator is equal to the spedal string value 

If so, then, the real instance variable is set to 
equal the currently executing instance, and the dass 
level is set to equal the dass level of the parent dass 
for the currently executing instance (i.e., correspond- 
ing to the base dass of the currently executing dass 
level; which equals the current dass level from the 
current execution block minus 1, i.e., the parent 
class). In this fashion, a method belonging to the par- 
ent dass may be performed even if the current dass 
has a method of the same name. 

In block 420, the method name assodated with 
the class level that has been identified which is resi- 
dent in the dassBlock field 32, described above in 
conjunction with FIGURE 3. A check is then made in 
block 422 as to whether there is such a method in the 
method table. If there is no such method, then the rou- 
tine branches to block 424, which generates a method 
error indication. 

If there is such a method, then a new execution 
block is created (426) as shown in FIGURE 6. At this 
point in the routine process, the actual instance, the 
adual dass level and the program to be used are 
known. The private and shared variables are then 
available and the exec block in FIGURE 6 is built Ac- 
cordingly, as a result of this processing, the real in- 
stance Is set as the instance value, the instance exec 
count is incrennented, the oirrent method and the ac- 
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tual dass level associated with the current method is 
indicated. The method performed will be associated 
with an earlier dass level than that indicated when the 
method Is inherited from a base dass. 

The routine then prepares to process by setting 
the current p-code address as the first p-code in- 
struction of the new method. The new execution level 
is placed at the top of the execution stack, and the 
routine branches to the executor/interpreter to exe- 
cute instructions. 

Instructions are executed under control of the 
cunrent (highest) execBlock on the execution stack. 
P-code instructions are executed in a manner which 
wilt be understood by those skilled in the art. Refer- 
ence may be made to the applicant's copending trav- 
elling program related application Serial No. 
07/863,552 which explains in conjunction with FIG- 
URES 14 and 15 p-code execution related opera- 
tions. 

In executing a p-code operation, all variables as- 
sociated with the p-code operation are determined, 
whether the variable is a literal or a local private, 
shared or global type, its value is located from the ap- 
propriate pool or if absent, a default action is taken to 
create the variable in the conrect pool. Once the vari- 
able locator is found, the cunrent value is isolated for 
use in the p-oode operation. 

In the preferred implementation, value assign- 
ments and disassignment are done using pointers 
and use counters. All values are extracted (and their 
use counts incremented) and tabularized prior to pre- 
paring any variables for p-code processing. The ap- 
propriate p-code executor routine is invoked, using 
the values which have been extracted from the liter- 
als and variables. The validity of the values is 
checked. For example, non-numeric strings are inval- 
id in arithmetic operations. Similarly, there are differ- 
ent contexts in which instance values and string val- 
ues are not respectively allowed. 

In executing instructions, the next p-code in- 
struction is selected as indicated by the current exec- 
Block. The values are extracted based on variables 
and literals indicated in the p-code instruction. The 
routine specifically associated with the p-code in- 
struction is then invoked. The following operations 
associated with executing p-code will be described in 
further detail: creating a new instance from dass, 
loading an existing cell as an object, storing/mailing 
a specified instance as a cell, invoking a method as- 
sociated with an instance, terminating the cell, provid- 
ing security for any sensitive function and exiting a 
method. After a p-code instruction is executed, the 
routine accesses the next instruction as indicated by 
the execBlock. 

As each method is executed, a mbcture of vari- 
ables: global, shared, private and local are all used. 
As a part of each instruction, as the values of the va- 
rious operands are gathered, the interpreter/execnjtor 



determines to which type of pool the variable is as- 
signed. For local variables, the pool is defined in con- 
junction with the execution block For private vari- 
ables, each instanceBlock contains a vector of pool 

5 elements, with one element for each class in the dass 
lineage. When a private variable is encountered, this 
vector is indexed by the method's dass level (as stor- 
ed in the method block when the method began) to ac- 
cess the variable pool containing the desired variable. 

10 For shared variables, each instanceBlock con- 

tains the pool head for all variables which are to be 
shared among the varkius d asses defined in the 
overall lineage. For global variables, the head of the 
global pool is stored in the cell with which the instance 

15 is associated. Once the pool is known, then the vari- 
able itself can be located using conventional means, 
such as a b-tree or hash look-up on the name. Literal 
values can be handled in a variety of ways. One way 
is to treat them as variables associated with the pro- 

20 gram dass definition itself. 

FIGURE 14 is a flowchart delineating the se- 
quence of operations in the create new instance sub- 
routine. The "create new instance" routine depicts 
how a new instance is initialized. Initially in block 

25 1402, a load class routine is used to establish an as- 
sodated dassBlock, such as shown in FIGURE 3. In 
block 1402, a new instance value is constructed and 
pertinent information is placed in the instance block 
such as the vector of heads for the private persistent 

30 variable pools associated with each dass level. The 
first element of the vector is the head for the variable 
pool for the most senk)r dass in the lineage, up 
through the last element in the vector which controls 
the private variables for the youngest dass in the lin- 

35 eage. The information loaded in the instance block 
further indudes the head of the shared persistent va- 
riable pool, the pointer to the associated dassBlock, 
and the pointer to the associated cell block. The ad- 
dress of the new instance value is provided in block 

40 1402. Thereafter, the doNow routine which begins at 
block 1420 is initiated, starting with the youngest 
class in the inheritance hierarchy. 

For a given instance, the classes with "create" 
methods are driven in order to establish the initializa- 

45 tion for the dasses in the lineage. 

When a new instance is created, it is generally 
necessary to make sure that the fundamental in- 
stance on which the new instance builds begin first 
and is autonnatically initialized. Thus, new instances 

50 are built, it is significant to build the oldest instance 
first and work toward the youngest There are, how- 
ever, exceptions to this general rule. The priority op- 
tion in the "create" method routine provides the ability 
to select either option. In block 1420, a fresh local va- 

55 riable pool is provkied as each dass level runs. 

A check is made in block 1422 to determine if the 
create method for the specified dass has a priority 
option or the specified dass has no parent base] spe- 
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cif led. If the new method for the specified dass has 
a priority option or if the specified dass has no par- 
ent, then the routine branches to block 1424, and the 
"create" method is invoked. Thereafter, the routine 
branches to block 1428 to routine to caller. This "ere- 5 
ate" method must explidtly invoke its parent's dasses 
create methods, if thte is deemed appropriate, tf block 
1426 detect that the ched< in b\ock 1422 indicates 
that the create method does not have "priority" option, 
then the routine reversing re-invokes block 1420 us- io 
ing the parental dass The instance is marked indicat- 
ing that create has been invoked. 

FIGURES 15A and 15B delineate the sequence 
of operations used to load a dass. It is used to load 
into storage a class program which is not known to is 
have been specifically used before. The parameter 
"dassName" is the name of the class to be loaded. It 
is possible that this may also be accompanied by a 
file or a library access informatbn. The load dass 
program begins by initially determining (block 1002), 20 
if the existing block already exists for the specified 
class name in storage. If it does exist in storage, then 
a check is made in block 1 004 to detenmine if the load- 
ing has been complete. If the loading is incomplete, 
then the routine is exited with an error Indication. This 25 
test determines whether the program is its own an- 
cestor to thereby detect circular inheritance which 
generates an error condition (1006). If the loading has 
been completed, then in b\ock 1008, the routine re- 
turns with a pointer to the dassBlock. If the check In 30 
block 1002 reveals that the program is not in storage, 
then a new dassBlock must be created correspond- 
ing to the respective dass load. This block will be de- 
leted in case of loading failure. 

The dassBlock b connected to the dass fist and 35 
a check is made to detemiine whether the dassBlock 
is incompletely loaded to detect for dncular inheri- 
tance errors. 

Thereafter, the routine proceeds to block 1012 to 
locate the dass program spedf ication in the local en- 40 
vironment, e.g., search libraries, files, etc. Afterlocat- 
ing the program specification in block 1012, in block 
1 014, a check is made to determine whether the spec- 
ification represents already compiled p-code that is 
processable by the current version of the compiler. If 45 
so. then the routine branches to block 1024 whero the 
p-code is loaded into storage. If the check in 1014 in- 
dicates that the specification does not represent al- 
ready compiled p-code, then a check is made in 1016 
to see whether the specification reflects source Ian- so 
guage that can be processed by the compiler. If the 
spedf ication reflects source language that cannot be 
processed by the compiler, then the routine is exited 
and an appropriate error message is generated 
(1018). 55 

If the source language can be processed, then 
the routine proceeds to block 1020 where the source 
code is compiled into p-code using an appropriate 



translator. As the p-code is loaded into storage, a 
hash is computed. A check is made to insure that the 
version of the compiler that oeated the p-code is 
compatible with the current executor. The hash of the 
original source program (or normalized version there- 
of as stored in the p-code) is copied into the dass- 
Block. It Is also possible that the source code itself 
may be saved. The dass authorization assigned to 
the p-code is thereafter established, as will be ex- 
plained further below. 

After the processing in blocks 1 020 and 1024, the 
hash of the p-code in the dass-Block is saved (1026). 
Various information is also supplied concerning the p- 
code to the dassBlock including the hash of the as- 
sociated p-oode, the address of the start of the pseu- 
do instructions, address of the start of the overall p- 
code. It is assumed that the dass level (which is the 
number of dasses in the aggregate class lineage) is 
equal to one. 

A check Is then made in block 1030 to determine 
whether the dass is derived from a base class. If the 
class is not derived from a base class, then the rou- 
tine branches to block 1 040 for merging new methods 
into the list associated with the dassBlock which will 
be explained further below. If the class is derived 
from a base dass, then the load dass routine is per- 
formed again for the base dass (1032). A check is 
made at 1034 to determine whether there is an error 
in the perform load dass executbn and, if so, then an 
error routine is executed in 1 036, due to the failure to 
load the current dass. If no error is deteded, then, at 
this point, the cunrent dass and the parent or base 
class have been loaded (as well as the parenf s par- 
ent class). 

In block 1038, a pointer is set to the base dass- 
Block to show that the new dass-Block is an exten- 
sk)n of the base dassBlock. Additionally, the new 
class level is set to one greater than that of the base 
to reflect the number of dasses in the lineage. Addi- 
tionally, the methods list is copied from the base dass 
to the new dassBlock. Processing continues at block 
1 040 where the new methods are merged into the list 
associated with the dassBlock (there may be existing 
methods already loaded from the base class). This 
merging indudes locating the explidt start of the p-oo- 
de instruction for each method. 

If new methods duplicate existing methods 
(which have t}een already loaded from the base or 
parent dass) then substitute the new methods as 
substituted. Whatever other aggregate data is need- 
ed for this dassBlodc is supplied. The incompletely 
loaded indicator is deared now that ail aspects are 
loaded and the routine returns to dassBlock pointer 

FIGURE 16 is a flowchart delineating the se- 
quence of operations in establishing a dass authori- 
zation. The routine authenticates and verifies the au- 
thorization of the class as it is loaded. This applies to 
classes loaded in either source fbnmat or compiled 
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code format Parameters used in this routine are the 
hash of the associated source or p-code image, the 
type of structure (source code language or p-code), 
the digital signature structure for the class definition, 
and the classBlock associated with the associated 
class. The routine returns the authorization structure 
for this code (or an error if the authorization definition 
or signature is invalid). 

The routine begins processing at block 1302, 
wherein it is determined if the signature is correct for 
the supplied hash value, if the signature is not correct, 
then an error is indicated (1304). If the signature is 
correct, then a check is made at block 1306 to deter- 
mine whether the type of structure is as indicated in 
the signature block, tf there is a failure to match, then 
in block 1307 an error routine Is invoked. If the type 
of structure is as indicated in the signature block, 
processing continues at block 1310. One or me 
checks are made at 1310 to detenmine whether the 
signature reflects the explicit authorization that has 
been assigned to this class. If so, then it is determined 
that the signer is trusted. This check can be made in 
several ways. 

First, the test can be made by testing if the public 
key belongs to a trusted party. Authorization can be 
determined by testing if the certificate belongs to a 
trusted party or by determining that the signer has 
been delegated authorization through certification or 
delegation by a higher (trusted) authority. Tests could 
include direct comparison, comparison of hashes, 
comparison of identification indicia, etc. 

If explicit authorization is not specified, then in 
{ some environments, it may be appropriate to infer au- ; 
thorization by virtue of information known about the 
signer's certifiers. Further details of such tests and 
how authorization can be delegated aro indicated in 
applicant's U.S. Patent No. 5,005,200, which patent is 
herein incorporated by reference. The digital signa- 
tures may imbue authorization In a number of possi- 
ble ways, including being signed by a specific public 
key or a certificate recognized by the current user, by 
being signed using a private/public key having in its 
certification hierarchy a trusted entity's public key or 
a certificate, or being signed with explicit assignment 
of program authorization using a protocol such as 
electronic document authorization as described in the 
methodology of the applicant's U.S. Patent No. 
5,005,200. 

If it Is determined by the checks in blocks 1310 
that the signer is trusted, then processing continues 
at block 1320. If trustable authorization isdetennined 
or can be inferred, then the digital representation of 
this authorizatk>n is stored in a structure accessible 
from the classBlock. If there is a failure in validation, 
so that the authentication and/or authorization cannot 
be confirmed, then the appropriate action (depending 
upon the precise failure, the environment, the imple- 
mentation and the user oonf iguration, etc.) must be 



taken, including suppressing use of the dass or as- 
signing a default authorization. 

Depending upon the implementation, various ex- 
ceptional actions may be necessary depending upon 

5 whetherthe code is not signed, the signature is inval- 
id, or the signer's authorization fe not recognized. It 
may be appropriate to halt execution or merely assign 
minimal (default) authorization to the incorrectly or 
unsigned dass definition. The authorization informa- 

10 tion established in the routine described in conjunc- 
tion with FIGURES 16 incorporates the program au- 
thorization information data structures described and 
utilized in applicanfs above-identified program au- 
thorization infbnfnation copending application. 

15 FIGURE 17 is a flowchart delineating the se- 

quence of operations of the '*test dass authorization" 
routine which tests to insure compliance with the pro- 
gram authorization information. This routine is in- 
voked by various functions within the Interpreter/exe- 

20 cutor whenever a sensitive operation is requested by 
an instance. Input consists of the specification of the 
type of function induding details such as the full file 
name, etc. The input is usually presented as type of 
request, request details. This requested operation is 

25 checked against the authorization obtained when the 
class was loaded and a determination is made as to 
whether the operation is permissible. 

A check is made in block 1802 to determine if the 
class Is "fully" authorized (i.e., any function is permit- 

30 ted). If the routine is fully authorized, then the routine 
branches to block 1850. If the dass is not fully autho- 
rized to perfbmri any sensitive operation, then proc- 
essing continues at block 1804 to determine if the re- 
quest type is defined within the program authoriza- 

35 tion information structure. If the request type is not 
defined within the authorization structure, then the 
routine branches to block 1870 where the request is 
denied for execution. If the check in 1804 Indicates 
that the request is defined then the routine tests for 

40 details of the request against the authorization struc- 
ture (1 806). A ched( is made at block 1808 to deter- 
mine if the request details fail the test If so, then the 
routine branches to block 1870 to return a "denied" 
response. If the request details are okay, then a check 

45 is made at block 1 850 to determine whether there are 
parametere spedfied by the interpreter/executor to 
impose an upper limit on the authorization that may 
be exercised by this (or perhaps any) cell. If there are 
no parametere specified, then the response "oka/* is 

50 returned. If the request is within any imposed limits, 
then the return "okay" b provided. 

FIGURES 18A. 18B and 18C delineate the se- 
quence of operations performed by the *Yeload dass" 
routine. This routine restores the dass definition for 

55 a dass which is associated with a stored instance in 
the cell and for which either the p-code and the source 
code are known. This particular dass definition is ak 
ready assodated with an existing instance in the cell. 
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The classes are stored in a cell so that the base dass 
definitions precede all classes which extend them. 

In reloading a class, it is necessary to rBestat)lish 
the dass exactly as it existed before. The reload dass 
routine begins at block 1202 where a new dassBlock 5 
is created which corresponds to the prospective load 
(block will be deleted in case of failure). The class- 
Block is connected to the dass list and an indication 
is made as to whether the dassBlock is incompletely 
loaded as previously described to detect circular in- io 
heritance. 

A check is made at block 1206 to determine 
whether dass p-code definition is already provided in 
the cell. If so, then the routine branches to block 1230 
and processes the p-oode image as canied in the cell. 15 
If the p-code definition is not present, then a check is 
made to determine if the dass source code definition 
is provided in the cell. If so, then the routine branches 
to 1220 and processes the source image as carried 
in the cell. If neither the p-code nor source code is 20 
present, then the routine proceeds to block 1210 
where the dass definition is Indicated by program 
name, by program version, by p-code and source 
hash. The name (and possibly the hash) of the dass 
is used to locate (another) local copy of the F>-code or 25 
the source. 

As indicated at block 1212 a test is made to de- 
termine whether the correct pmgram image exists. If 
the correct program image does not exist, then the 
routine branches to 1213 and generates an error in- 30 
dication. If the correct program image does exist, then 
a check is made at block 1214 to determine if the local 
I version of the dass is p-code. tf so, then the routine 
' branches to block 1230. If the local version is not 
source code as determined in block 1216, then it is 35 
determined, than an enror has occurred, and process- 
ing continues within an error routine at block 1217. 

If the source code has been located, then at block 
1 220, it is compiled and the hash of the source is conrv 
puted. If the computed source hash matches that de- 40 
fined in the authenticated aspect of the cell, then the 
class Is accepted. It is possible that the source hash 
is based not on the exact source, but rather a normal- 
ized form, for example, with the comments removed 
and nonessential spacing deleted. Thereafter, in 45 
block 1220, the dass authorization is established as- 
sociated with the source code. The source definition 
is compiled using whatever compiler Is appropriate to 
the source definition if multiple languages are sup- 
ported. 50 

Processing then continues in block 1232. If the 
prior processing involved a block 1230, then the locat- 
ed version of the p-oode \s loaded from the local file 
repository or within the cell itself. The hash of the p- 
code is computed as it Is loaded. A check is made to 55 
ensure that the precompiled p-code Is in a format eli- 
gible for being processed by this interpreter/executor 
and the class authorization Is established that is as- 



sodated with the p-code. A check ts made to deter- 
mine whether the computed hash of the p-code 
equals the expected value as defined in the authen- 
ticated part of the cell. If there is a match, then the 
class is accepted. If not, an error indicator is generat- 
ed. The processing at 1232 additionally saves the 
hash of the original source which is given in p-oode. 

In block 1234, if the given hash of the ordinal 
source code matches that spedf led in the cell's p-co- 
de dass definition, then the cell is accepted. Acheck 
then is made at block 1236 to detemnine if the dass 
is accepted. If the class is accepted, then processing 
continues at block 1250. At block 1238, processing 
steps are implemented which consider alternate pro- 
gram dass revision levels. This processing allows, if 
desired, for a substitute version of the progranvthere- 
fore, the hashes of the source or the p-code cannot 
match, so compatibility is based on explidtly stated 
version/revision fields. 

The routine compares the revisionA^ersion level 
of the dass program as defined (and used) In the cell 
with the range of revision/version levels stipulated 
with the program image which Is being processed (as 
found in local repositories or inserted into the cell). If 
the revision/version level used in the cell instance 
data falls into the category supported by the level of 
the program, then the program is allowed to be used. 

It may also be useful In some embodiments to en- 
sure that the different program Is digitally signed or 
authorized by the same entity that was responsible 
for the revision/version associated with the instance. 
In this case, the digital signature of the cell reference 
must also carry the digital signature. The revi- 
sion/version of the actual program can validly pre-da- 
te or post-date that affiliated with the instance. 

The most common valid mismatch will be when 
the program post-dates the instance's version-the 
program simply carries the Information of the older 
compatibility level It supports. The less apparent 
case is when the program may actually be created 
with the stipulation that It supports some range of lev- 
els that exceed its own level. This may be reasonable, 
though possibly not usual, when program upgrades 
are planned and it is known that future data struc- 
tures (at least for some range of future program lev- 
els) will be compatible with the older program levels. 

In block 1240, a check is made to determine if the 
class \s not yet accepted, tf the dass Is not accepted, 
then processing branches back to block 1 21 0 in an at- 
tempt to find another dass definition candidate hav- 
ing a compatible description given in the cell spedfl- 
cation. 

If the class is accepted, a check is made in block 
1250 to detenmine whether the dass is derived from 
a base dass. If the dass Is not derived from the base 
class, then processing continues in block 1260. If 
processing Is derived from the base dass. then the 
processing continues at block 1252. 
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In a stored cell (FIGURE 10), the associated base 
class Is specifically constructed to precede the ex- 
tended class-thereby allowing direct determination of 
the base classBtock. The only check that needs to be 
done is that it corresponds to the base class name as 5 
given in the extension. The base dass should already 
be loaded and is indicated by the current cell specifi- 
cation. 

Thereafter, the pointer is set to the base class- 
Btock to show that the new dassBlock is an extension io 
thereof. The incremented extension count \s set in the 
new dassBlock. Thereafter, block 1252 processing 
condudes with copying the methods list from the 
base dass to the new dassBlock. The routine con- 
cludes at block 1 260 where new methods are merged is 
(as isolated by p-code) into a list assodated with the 
dassBlock in the same manner as the merged new 
methods processing was accomplished in block 1040 
associated with the load class routine described in 
FIGURES 15Aand15B. 20 

FIGURE 19 is a flowchart delineating the se- 
' quence of operations in the "exit method" function. 
This function is driven by an exit or return from a 
method. The current executive block is terminated 
and control is passed to the previous execution level. 25 
If an instance is deleted (either explicitly through the 
delete built-in function or implicitly when no more va- 
riables reference the instance) while it is still execut- 
ing, then "delete pending" flag is set and the delete 
will be deaned up as soon as all currently active 30 
methods (execBlocks) terminate. Once in this state, 
it is up to the implementation as to whether additional 
activations can be directed against this instance, or 
whether there should be a way for the instance to re- 
instate itself (perhaps by assigning its instance to an- 35 
other variable). An implementation could even allow 
an ^indelete" to dear such a pending delete state. 

Turning to block 1502, the built-in function re- 
leases the local variable pool assodated with the 
execBlock. The execBlock is removed from the top of 4C 
the execution stack and release storage. Thereafter, 
the instance's block execution use count is decre- 
mented. A check is then made at block 1 506 to deter- 
mine whether the execUse is greater than zero. If so. 
the routine branches to block 1520. If the execUse is 45 
not greater than zero, then a check is made at 1508 
to determine whether there is a pending explicit delete 
(the variable use count equals zero). If so, then in 
block 1510, the instance is deleted. 

A check Is then made at block 1 520 to determine so 
whether there is another execution block on the stack. 
If so, then the routine branches to block 502 to exe- 
cute the instrudions. If not, the routine execution 
ends and the routine returns to block to 336 in the ini- 
tial interpreter/exeojtor activity processing. ss 

FIGURE 20 Is a flowchart delineating the se- 
quence of operations for the "delete instance" built-in 
function. An instance Is deleted when all references 



to it are unassigned or when it Is explicitly deleted with 
the "delete" built-in function. Delete instance proc- 
essing begins at block 1102 where iterations for each 
dass in the lineage are set up starting with the yourv 
gesL After the iterations, the routine branches to 
block 1120. A check is made at block 1104 to deter- 
mine whether there is a destroy method defined spe- 
cifically for this class (not simply inherited). If there is 
no destroy method defined by the dass, then the rou- 
tine branches back to 1102 of the iteration process- 
ing. If there is a destroy method defined specifically, 
then the specific destroy method Is performed at 
block 1106. 

Thereafter, a check is made at block 1108 to de- 
termine if this destroy method invoked its parent's de- 
stroy method. If the destroy method did not invoke its 
parenf s destroy method, then the routine branches 
back to block 1102 for iteration. Thereafter, process- 
ing continues at block 1120 where variables are de- 
leted in all private pools from youngest to eldest in 
class lineage. Additionally, variables in the shared 
pool are deleted. The classAct is decremented, which 
is the count of active instances for associated dass- 
es. Additionally, the celt ACT variable is decremented, 
which is the count of active instances in the celt. 

FIGURE 21 is a flowchart delineating the se- * 
quence of operations in the "reset variable" value rou- 
tine. This logic is used whenever the value of the va- 
riable is reset. In block 1902, the current value is de- 
leted. Thereafter, in block 1950, the new value Is set 
A check is then made (1952) to determine if the new 
value is an instance. If the new value is an instance, 
then processing continues in block 1954, wherein the 
instance UseCount is incremented. If the new value 
is not an instance, then the routine returns to the call- 
ing routine. 

FIGURE 22 is a flowchart delineating the se- 
quence of operations performed in deleting a current 
value. In block 1602, a check is made to determine if 
the value's cunrent value is a string. If the current val- 
ue is a string, then the string is released (1604) and 
the routine branches to block 1650. If the check in 
block 1602 reveals that the cunrent value Is not a 
string, then a check is made in 1606 to determine if 
the variable current value is an instance. If so, then 
the instance UseCount is decremented (1608). 
Thereafter, a check Is made to determine if the in- 
stance UseCount is greater than zero. If the Instance 
UseCount and the instance execCount are greater 
than zero, then the routine branches to 1 650. If the in- 
stance UseCount Is not greater than zero, then the in- 
stance Is deleted in block 1623. Return is wade to the 
calling routine (1650). 

The present invention additionally contemplates 
various other restore operations which have not been 
heretofore specifically addressed. For example, a re- 
store instance routine is contemplated in which the 
associated dassBlock (whk;h Is already established) 
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is located. The instance is then connected to the as- 
sociated classBlodc, and the associated cell block. 
The shared variable pool for the instance is restored 
as is the private variable pool. 

Pools may be restored by connecting each vari- 
able to the associated pool definition header and con- 
necting each variable to its assigned value, if any. 
Values may be restored as follo>Ars: for string values, 
a value block is created with a specified string value. 
For instance values, a value block is created referring 
to the associated instance. In the preferred embodi- 
ment, the information controlling the instance, i.e., 
pools, class pointers, etc., is stored directly in the in- 
stance value block. The restore instance function is 
utilized for instance values. 

With respect to restarting an Instance being re- 
loaded (after all variables, etc., have been attached), 
if the dass was digitally signed, then the signature is 
verified, and any execution authorization bound with 
the signature is stored in conjunction with the class 
definitbn. If the class is derived, then the base class 
is also located (it may already t>e loaded) and loaded 
if necessary. 

With respect to loading a subcell the following op- 
erations may be performed: 
ReloadCell 

create an instance value for the face instance 
of the subcell return this instance to the caller. 

The caller can then invoke the instance value as 
if it were any other instance. 

The dispatcher uses the cell associated with the 
instance to determine which global pools is affiliated 
with references to global variables. 

The invention is designed to allow complete cells 
to be invoked and logically encapsulated within other 
cells. Such 'interior* cells are known as "sut>celts." In 
the present implementation of the invention, each 
subcell has its own distinct global variable pool 
shared by the instances within the cell. It is possible 
in alternate implementations to share the global pool 
among all subcefis, however, this would require han- 
dling collisions of global variables when two cells are 
combined (when one cell is invoked by another, and 
they both contain similarly named global variables) 
such that one version of the variable is overlaid by an- 
other. 

Turning now to verifying critical operations, we 
first consider verifying a dass. The dass definition, 
especially one performing sensitive operations, is 
digitally signed by an authority trusted by the popula- 
tion sharing the dass definition. Depending on the inv 
plementation and drcumstances, the signature may 
stipulate (in various ways) the explicit or implicit au- 
thorization which is granted to the dass. The dass 
definitbn may be signed in etthersource form or p-co- 
de form, or both. 

Class definitions which are not signed are sup- 
plied a default (usually minimal) authorization which 



inhibits them from participating in sensitive opera- 
tions. Alteratively, in some implementations, it may be 
appropriate to treat an unsigned or unauthorized 
class as entirely invalid and not permitted to execute. 

5 Digitally signing class definitions inhibits the pos- 

sibility that bogus or Trojan horse dasses could be 
used to performed mischief. Sensitive functions, at 
least, must be protected. In some environments, it 
may be desirable to insure that all classes are explic- 

10 itiy authorized. The preferred embodiment of the in- 
vention allows the trust criteria to be decided by the 
individual user or the user's organization. 

The hash of the class definition program (in 
source or p-code form, as appropriate) is computed 

15 as it Is loaded. This hash, combined possibly with 
other authorizing information, is validated using digi- 
tal signature(s). 

Techniques from applicant's Program Authoriza- 
tion information application should be understood as 

20 applying to object class definitions. This allows spe- 
cific designation of the functions which a cell Is per- 
mitted to execute. 

With respect to validating a cell, signing a cell as 
it is stored or transmitted to another user inhibits the 

25 possibility that it could be altered by enror or by a mal- 
icious adversary. (Even if it Is tampered with by the 
sender then this can be later proven). 

In the preferred instantiation of the invention, 
only essential parts of the cell are signed, induding: 

30 the name, hash and other identifying references to 
the various classes; the variable pools, the variables 
and values and their mutual relations and their rela- 
tionship with the various classes, instances, and 
pools and variables. 

35 The dass definitions themselves need only be 
signed by proxy (by name, other identifications 
and/or hash values), and may thus be safely append- 
ed or removed from the stored cell without invalidat- 
ing the overall digital signature. However, by having 

40 the dass programs validated by their hashes, this in- 
sures that an incorrect, altered or tampered version 
cannot be substituted. This provides flexibility with 
security. 

With respect to validating a sensitive function, 
45 some (bui It-in) f u notions as well as any "arbitrary" as- 
sembler language (or other function which can affect 
the system) operating outside of the invention's inter- 
preter/executor, are potentially sensitive and require 
trust on the part of the dass which invokes such func- 
50 tions. The invention enforces security by suppressing 
any function activity deemed sensitive, unless the in- 
stance requesting the function is assodated with a 
class authorized to perform the functton. 

If a trusted dass invokes sensitive functions us- 
55 ing information originating in untrusted ways (such as 
a parameter from an untrusted caller; or the result of 
invoking another (possibly untrusted) instance), then 
the trusted dass is obliged to validate the information 
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obtained from any source not known to have the same 
level of authorization trust (or higher). 

Some sensitive built-in functions include: read- 
ing, writing, creating and erasing files, performing 
digital signatures. Any use of *'external'' modules or 5 
functions written in assembler, or which operate in 
some other way outside of direct monitoring of the in- 
vention's interpreter/executor, must also be consid- 
ered potentially risky. Such functions should be iso- 
lated into trusted classes and appropriately autho- io 
rized. If these are properly written, then such trusted 
classes can then be used by other nomnal (untrusted) 
classes to access these risky capabilities. 

Other variations and modifications to the exem- 
plary embodiment(s) will be apparent to those skilled is 
in the art while yet retaining some or all of the novel 
features and advantages of this invention. All such va- 
riations and modifications are intended to be included 
within the scope of the appended claims. 

20 

Claims 

1. In a communication system having a plurality of 
digital computers coupled to a channel over 25 
which computers exchange digital messages, a 
method for processing Information among said 
computers comprising the steps of: 

executing on a first computer a sequence 
of digital program instructions Including instruc- 30 
tions which detemnine at least one next destina- 
tion that receives the sequences of instructions, 
! said sequence of instructions defining a plurality 
of associated programs, which are bound togeth- 
er; and 35 

transmitting to said next destination digital 
information comprising at least said plurality of 
associated programs together with accompany- 
ing digital data associated with said sequence of 
instructions. 40 

2. In a communications system having at least one 
computer having a main memory, a method for 
operating said computer comprising the steps of: 

constructing a first digital data structure in 45 
said memory, including digital data identifying a 
plurality of programs associated with said data 
structure and 

constructing at least one second digital 
data structure defining a program dass control so 
block which stores a list of functions performed 
by an associated one of said plurality of pro- 
grams. 

3. A method of operating a computer system conD- ss 
prising the steps of: 

loading a digital celt into menfn>ry which 
identifies a plurality of programs. 



processing an incoming function request 
by accessing said digital cell to determine which 
of said plurality of programs is to perfbnm said 
function request, and 

executing a program for performing the re- 
quested function. 



24 



EP 0 638 860 A2 



COMMUNICATIONS CHANNEL 12 

I 



,8 



10 

-4-, 



MODEM 
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MODEM 



KEYBOARD/ 
CRT 
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NON- 
VOLATILE 
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TERMINAL 
N 



tig, 1 



25 



EP 0 638 860 A2 



cellBlock 



12. 



MH globalPool: 
I6H 



18"- 

20 
22 ^ 



nextCell: — ) Next cellBlock 



Pool head for global variables 



cellldent: 



cell identification 



cellFace Instance (pointer to instance for handling outside f^i^^ ^ 

requests) 



pointers to file and certificate tags 



classTable Pointer to classes for this cell 



cellSignature: _> digital signature structure for cell 
as it existed when cell received 



classBlock -^23 



25. 


classLink link for other classBlocks in Cell 




parentClass — >classBlock from which this is extended 


26, 


numLevels: = number of classes in total lineage 


28^ 


className Name of this class 




classpgm to program block of associated program 






method Table: — > table of valid methods for lookup: 








Each method entry has the format: 








Linkage for other entries in table 








classBlock associated with definition of method 








Offset of start of pCode for method in associated classProgram 








Length of method name 








Name of method (normalized to lower case) 






34 
1 








classAuth: — >authenticated authorization structure 


36' 


lowest and highest levels of program making processable instances 
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proqramBlock^ 



38^ 


nextProgram: 


— > next proaramBlock 


39^ 


programlnfo 


— > program Identification element 


50, 


pgmlmage 


V storage where program structure begins 
and pointer to source code 


42^ 


pgmSize: 


= size of pCode program 




type of program (O'REXX, O'BASIC, etc) 


46 u 


hash of source 




hash of compiled pCode 


49 


classCount: 


number of classes referencing programBlock 


51 ^ 


pgmAuthTable - 


^ authenticated authorization structures 



Fi^^ ^ ^ 52 

programStructure ^ 

Site of entire program Stmcture 



54^ 

progldent: Program identification 



List of methods and class names and pCode offsets 



58 Variable Tables 



60^ Literal (constant) Tables 



pCode instructions 



61 
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nextlnstr: 


— > next pCode instruction 


66^ 


classPtr: 


— > classBlock 


68^ 


instanceExec: 


—> instance being executed 


70 V. 


localPool: 


— > pool for local variables 


72^ 


prevExecBlock: 


~> Previous execBlock 



73-. instanceValue 





classRef : 


— > classBlock for instance's class 






cellRef: 


— > cellBlock for this instance 




78 


pendDelete 


= 1 if "DELETE" has been directed to instance 


79^ 


sequence #: 


identifies last store operation 






execCount: 


Number of active execBlocks for this instance 


81 

82^ 


scan indicators: 
useCount: 


identifies particular save operation 

Number of pointers to this block 
(includes variables, FACE INSTANCE, etc.) 




84, 


levelCount: 


(Equal to numLevels in associated classBlock) 


86- 


sharedPool: 


Pool head for SHARED variables 




88. 


privatePools: 








Pool head for private variables of eldest parental class 








Pool head for private variables of next eldest class 








• 








Pool head for private variables of youngest class 
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variableBlock 



92, 



linkVar: linkage to another variableBlock in same pool 



93 ^ 



valuePtr: — > valueBlock giving variable's value 



9^ "I qualVars: If STEM, this is pool head 

for qualified variables 



95^ 
96 



length of variable name 



variabieName 



98 
99^ 



100 



valueType Type of value: string, instance. 


For string Value: 






valueLength: 
valueString: 


Length of string 
value of string 




For instance value: 






valuelnstance: 


instanceBIock | 









MasterBlock ^ lOI 



Contains overall information 



102, 
103^ 
104 
105^ 



106 
I07U 



mainCell — > cellBlock for primary cell 



messageRef : — )> messageReference Table 



pgmTable: — ^> Table of all loaded programs 



execStack — latest execBlock in execution stack 



. List of attached files 



certificate cache list 
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STORED CELL: 



Cell identification 



following material optionally ENCRYPTED and compressed 



Included CLASS programs 



Class Program 1 



Class Program 2 



Class Program P 



Following material optionally AUTHENTICATED: 



Program reference vector 



Program reference 1 



Program reference 2 



• 



Program reference N 



Cell (and sub-cell) Vector 



Cell 1 (Main CELL) 



Cell 2 (first subCell) 



Cell K (last subCell) 



Data file Vector 



Data file Specification 1 



Data file 2 



Data file (last) 



Authenticating signatures 



Certificate Specification Set 
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126^ 

128- 
130. 
132- 

135 



134 



136 



rogram 
Program Date 



Program Identifier 



Program Executable(s) (source, pCode, or both) 



Program Mode (0 = source, 1 = pCode) 



Executable Image: 
For source, this is a sequence of program instructions 

For pCode, this is a structure defining: 

- pCode instructions, 

- method names and starting pCode offset 

- name of the PARENT (BASE) class (if extended) 

- variable names and uses 

- literal {"constant") values 

- etc 



Possible second executable 



Program Authorization/Signature (If any) of Program Identifier 



128 

^Program Identifier 



138. 

142^ 

144^ 
146 



1-18 
150 



Program Type (REXX, BASIC, etc) 



•Program X.209 Assigned Object Identifier 



Program Name (for display) 



Program Revision Level 



•Compatibility with data produced by other revisions: 



Lowest program revision producing compatible data 



Highest program revision producing compatible data 



Hash of SOURCE program 



Hash of pCode program (if available) 



T 
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Program Reference: ^|5| 



Program Identifier 



152 



Integer (in Program Vect) of PARENT CLASS program (if any) 



Cell: 



.118 



Fig. UD 



156 
158 

leo V 

162 
I6<1> 
166 

167 
168 

170 

172, 
174 

176. 



^- Cell Identifier 



Instance Vector (one of each instance defined in this cell): 



Index of Program Reference within Program Reference Vector 



Index of class within program (always = 0 for 1st release) 



SHARED VariablePool 



Vector of PRIVATE Variable Pools: 



PRIVATE VariablePool for Eldest Class in lineage 



PRIVATE VariablePool for Class extended from eldest 



PRIVATE VariablePool for youngest class in lineage 



Global VariablePool 



DataFile Tag References 



certificateTag 



l7e^VariablePool: 



ITS'" 
180" 

184 



Variable 1 



Variable 2 



last Variable in pool 



tig- 
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Variable: 



183- 
184. 



Variable Name 



Variable Value: 
If variable is a STRING. 

then this is an OCTET STRING 
If variable is an INSTANCE within this SAME CELL, 

then this is an INTEGERindex within InstanceVector 
If variable is an INSTANCE within a DIFFERENT cell, 
then this is a SEQUENCE of INTEGERS: 

the INTEGER index within instanceVector 
the INTEGER index within CellVector. 
If variable is a STEM variable with no assigned value, 
then this is a NULL item. 

(If this is a simple (non-STEM) variable with no assigned value 
then the variable item is not included at all.) 



Cellldentifier 156 



186^ 
187- 

188^ 

189. 

190. 



Cell Format Code ( = 0 for first implementation) 



Moment of construction (date, time cell was built) 



Cell Category Identifier (X.209 object identifier) 

(X.209 object identifier for type of cell in an application) 



Cell category Name (to display application classification) 



Cell Instance Identifier (X.209 object id for this individ 
(X,209 object id for this individual cell) 



Cell Instance Name (to quickly display cell's unique name) 



I9r 

192^^ Cell Instance Title (more instance detail for display) 
193- 
194. 
195 



Cell Instance Qualifiers (more information to identify cell) 



196. 



First Qualifier 



Second Qualifier 



• 



Last Qualifier 



tie- tlO 
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DataFileSpecification 



200^ 


UseCount: Number of cells using this file. 


202^ 


datatype: Whether this is record, stream, or other type 


204^ 


fileContent 








First (or only) record OCTET (entire file, if stream file) 








Second record OCTET (if record file) 








• • • 








Last record OCTET 













208 
210 



174 




FileTag 




attachldentifier: 


String identifying file 


dataFileReference: 


Index to DataFile Specification 


TagUseCount: 


Number of "AttachFile" requests from cell. 
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Certification Specification: 



212 



useCount: Number of references: 

- TagUseCount in each (sub-)Cell 

- signatures on signed variables 

- references by other certificates in cache 



214 



identifying Hash: hash of the certificate 



216 ^ certificatelmage 



Certificate Tag --IT'S 



220' 



identifying Hash: hash of the certificate 



tagUseCount: Number of uses within home cell. 
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create new 
classBlock 



loadCell 




Dispatcher 
Loop Termination 
request? 



termination 



Get First/Next Incoming 
Message; Perform Specified 
Method of Instance Using 
Message 



0336 



Discard 
Message 



0340 



Termination 
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Is "instancelndication 
an instanceValue? 




Is Instancelndicator = 
SDecial string value 



Is Instancelndicator = 
special string value".." 




set: reallnstance 

classLevel 

go to Find Method 



0404 



0408 



set: reallnstance 

classLevel 

go to Find Method 



0412 



set: reallnstance 

classLevel 

go to Find Method 



Find Method 



Find Method 
Name in Method 
Table assoc. with 
classLevel 



0420 



Is there any 
such Method? 




Create a 
New ExecBlock 
(Fig 6.) 



0426 
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1402 



Establish Association 
classBlock construct 
NewlnstanceValue 
Build InstanceBlock 



rig. u 



doNew: Provide Fresh 
LocalVariable Pool 



1420 




1424 



Invoke Method 



1426 



Call doNew using 
Parent class 




1428 
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LoadClass 



1002 

Is existing 
classBlock for 
sflassNameL 



exist 



1004 



Loading ^ '"^^"^P 
complete? 




1006 



exit/error 



1010 



Create new 
classBlock 



1008 



Return with 
Pointer 



Located 
classProgram 
spec. 



1012 



- 1014 




1018 



Error 



0 
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Fig. 13E 




Set Pointer; Set 
NewClasslevel ; Copy 
Methods List 



1040 



Merge New 
Methods 
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Is local versiorv 
source? 



No 



Establish class 
Authorization 
associated with 
source. Compile 
source Def . 



J 220 



Computer Check 
HASH Save 
HASH 



1232 




Consideration of 
revision levels 



1238 

I 



1217 

— i 

Error I 



1230 



Load located 
pCode 



6 
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Exit Method 



1502 

/ 



Release 
Local 
Variable Pool 





1508 



Yes 



1510 



Delete 
Instance 



tig. 2€ 

Delete Instance 



1 102 



Iterate for each 
class in lineage 



No 




No 



Return 



0336 



> 



1104 




Perform 
Destroy 
Method 



1108 




Delete 
Variables 



,1120 
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Reset Variable Value 



1902 



Delete - 
Current 



1950 



Set New 
Value 



1952 




Fig. 21 



Delete Current Value 



1602 



1604 




1606 




Decrement use 
count 



" 1620 




1624 



Delete Instance 



1650 



Return 



J 
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